~ubuntu-branches/ubuntu/vivid/monit/vivid-proposed

.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)

.    ds C`

.    ds C'

.\"

.\" Avoid warning from groff about undefined register 'F'.

.de IX

..

.nr rF 0

.if \n(.g .if rF .nr rF 1

.if (\n(rF:(\n(.g==0)) \{

.    if \nF \{

.        de IX

.        tm Index:\\$1\t\\n%\t"\\$2"

..

.        if !\nF==2 \{

.            nr % 0

.            nr F 2

.        \}

.    \}

.\}

.rr rF

.TH MONIT 1 "www.mmonit.com" "October 29. 2014" "User Commands"

\&\fBmonit\fR is a utility for managing and monitoring processes,

programs, files, directories and filesystems on a Unix system.

Monit conducts automatic maintenance and repair and can execute

meaningful causal actions in error situations. E.g. Monit can

start a process if it does not run, restart a process if it does

not respond and stop a process if it uses too much resources. You

can use Monit to monitor files, directories and filesystems for

changes, such as timestamps changes, checksum changes or size

changes.

Monit is controlled via an easy to configure control file based

on a free-format, token-oriented syntax. Monit logs to syslog or

to its own log file and notifies you about error conditions via

customizable alert messages. Monit can perform various \s-1TCP/IP\s0

network checks, protocol checks and can utilize \s-1SSL\s0 for such

checks. Monit provides a http(s) interface and you may use a

browser to access the Monit program.

You can use Monit to monitor daemon \fBprocesses\fR or similar

programs running on localhost. Monit is particularly useful for

monitoring daemon processes, such as those started at system boot

time from /etc/init.d/. For instance sendmail, sshd, apache and

mysql. In contrast to many other monitoring systems, Monit can act if

an error situation should occur, e.g.; if sendmail is not

running, monit can start sendmail again automatically or if

apache is using too many resources (e.g. if a DoS attack is in

progress) Monit can stop or restart apache and send you an alert

message. Monit can also monitor process characteristics, such as

\&\fBfilesystems\fR on localhost. Monit can monitor these items for

changes, such as timestamps changes, checksum changes or size

changes. This is also useful for security reasons \- you can

monitor the md5 or sha1 checksum of files that should not change

and get an alert or perform an action if they should change.

Monit can monitor \fBnetwork connections\fR to various servers,

either on localhost or on remote hosts. \s-1TCP, UDP\s0 and Unix Domain

Sockets are supported. Network test can be performed on a

protocol level; Monit has built-in tests for the main Internet

protocols, such as \s-1HTTP, SMTP\s0 etc. Even if a protocol is not

supported you can still test the server because you can configure

Monit to send any data and test the response from the server.

exit value indicate an error. This means that you can use Monit

on localhost such as overall \s-1CPU\s0 usage, Memory and Load Average.

\& $ monit \-t 

Once you have a working Monit control file you can start Monit

from the console, like so:

If all goes well, Monit will now detach from the terminal and run

as a background process, i.e. as a daemon process. As a daemon,

Monit runs in cycles; It monitor services, then goes to sleep for

a configured period, then wakes up and start monitoring again in

an endless loop.

   Reset Monit's unique \s-1ID.\s0 Use with caution

   Print \s-1MD5\s0 and \s-1SHA1\s0 hashes of the file or of stdin if the 

\&\fImonitrc\fR. The default location for this file is ~/.monitrc. If

this file does not exist, Monit will try /etc/monitrc, then

\&\f(CW@sysconfdir\fR@/monitrc and finally ./monitrc. The value of

\&\f(CW@sysconfdir\fR@ is given at configure time as ./configure

\&\-\-sysconfdir. For instance, using  \fI./configure \-\-sysconfdir

/var/monit/etc\fR will make Monit search for \fImonitrc\fR in

To protect the security of your control file and passwords the

control file must have permissions \fIno more than 0700\fR

the arguments in this file, the command-line arguments take

statements in a free-format, token-oriented syntax.

.PP

Comments begin with a '#' and extend through the end of the line.

.PP

Otherwise the file consists of a series of service entries or

You can use noise keywords like 'if', 'and', 'with(in)', 'has',

\&'us(ing|e)', 'on(ly)', 'then', 'for', 'of'  anywhere in an

entry to make it resemble English. They're ignored, but can make

entries much easier to read at a glance.  Keywords are case

A global set-statement starts with the keyword \fIset\fR and the

The include statement consists of the keyword \fIinclude\fR and

a glob string.

.IP "2. One or more service entry statements." 4

.IX Item "2. One or more service entry statements."

Each service entry consists of the keywords \fIcheck\fR, followed by

the service type. Each entry requires a \fBunique\fR descriptive

name, which may be freely chosen. This name is used by monit

to refer to the service internally and in all interactions

with the user.

Currently, eight types of check statements are supported:

.IP "1. \s-1CHECK PROCESS\s0 <unique name> <\s-1PIDFILE\s0 <path> | \s-1MATCHING\s0 <regex>>" 4

<path> is the absolute path to the program's pidfile. If the

pidfile does not exist or does not contain the pid number of a

running process, Monit will call the entry's start method if

defined.

<regex> is alternative process specification using pattern matching

to process name (command line) from process table instead of pidfile.

The first match is used so this form of check is useful for unique

pattern matching \- the pidfile should be used where possible as it

defines expected pid exactly (pattern matching won't be useful for

Apache in most cases or for processes which start child processes using

fork/clone as the child will match the same pattern temporarily).

The pattern can be obtained using \fImonit procmatch \*(L".*\*(R"\fR \s-1CLI\s0 command

which lists all processes visible to Monit or using the \fIps\fR utility.

The \*(L"procmatch\*(R" \s-1CLI\s0 command can be used to test your pattern as well.

If Monit runs in passive mode or the start methods is not defined,

Monit will just send alerts on errors.

.IP "2. \s-1CHECK FILE\s0 <unique name> \s-1PATH\s0 <path>" 4

<path> is the absolute path to the file. If the file does not

exist or disappeared, Monit will call the entry's start method if

defined, if <path> does not point to a regular file type (for

instance a directory), Monit will disable monitoring of this

entry. If Monit runs in passive mode or the start methods is not

defined, Monit will just send alerts on errors.

.IP "3. \s-1CHECK FIFO\s0 <unique name> \s-1PATH\s0 <path>" 4

<path> is the absolute path to the fifo. If the fifo does not

exist or disappeared, Monit will call the entry's start method if

defined, if <path> does not point to a fifo type (for

instance a directory), Monit will disable monitoring of this

entry. If Monit runs in passive mode or the start methods is not

defined, Monit will just send alerts on errors.

.IP "4. \s-1CHECK FILESYSTEM\s0 <unique name> \s-1PATH\s0 <path>" 4

<path> is the path to the filesystem block special device, mount point,

file or a directory which is part of a filesystem. It is

recommended to use a block special file directly (for example

/dev/hda1 on Linux or /dev/dsk/c0t0d0s1 on Solaris, etc.) If you

use a mount point (for example /data), be careful, because if the

filesystem is unmounted the test will still be true because the mount

point exist.

Monit will disable monitoring of this entry. If Monit runs in

passive mode or the start methods is not defined, Monit will just

send alerts on errors.

.IP "5. \s-1CHECK DIRECTORY\s0 <unique name> \s-1PATH\s0 <path>" 4

<path> is the absolute path to the directory. If the directory

does not exist or disappeared, Monit will call the entry's start

method if defined, if <path> does not point to a directory, monit

will disable monitoring of this entry. If Monit runs in passive

mode or the start methods is not defined, Monit will just send

alerts on errors.

.IP "6. \s-1CHECK HOST\s0 <unique name> \s-1ADDRESS\s0 <host address>" 4

ip-address string on a dotted decimal format. Such as,

.IP "7. \s-1CHECK SYSTEM\s0 <unique name>" 4

The system name is usually hostname, but any descriptive name can be

used. You can use the variable \f(CW$HOST\fR as the name, which will expand to

the hostname. This test allows one to check general system resources

such as \s-1CPU\s0 usage (percent of time spent in user, system and wait),

total memory usage or load average. The unique name is used as the

system hostname in mail alerts and when M/Monit is configured, then

also as initial name of the host entry in M/Monit.

.IP "8. \s-1CHECK PROGRAM\s0 <unique name> \s-1PATH\s0 <executable file> [\s-1TIMEOUT\s0 <number> \s-1SECONDS\s0]" 4

<path> is the absolute path to the executable program or script.

The \fIstatus\fR test allows one to check the program's exit status. If

program will not finish within <number> seconds, Monit will terminate

it. The default program timeout is 600 seconds (5 minutes). The output

of the program is recorded (up to 1kB).

\&\fI\-l\fR command-line switch (or the keyword \fIset logfile syslog\fR

Alternatively, you can use the \fI\-d\fR command line switch to set

may be useful in some situations, but Monit is primarily designed

Calling monit with a Monit daemon running in the background sends

immediately. Calling monit with the quit argument will kill a

The \fIset init\fR statement prevents Monit from transforming itself

into a daemon process. Instead Monit will run as a foreground

process. (You should still use set daemon to specify the poll

cycle).

.PP

This is required to run Monit from init. Using init to start

Monit is probably the best way to run Monit if you want to be

certain that you always have a running Monit daemon on your

system. Another option is to run Monit from crontab. In any case,

you should make sure that the control file does not have any

syntax errors before you start Monit from init or crontab.

.PP

To setup Monit to run from init, you can either use the set init

statement in Monit's control file or use the \-I option from the

command line. Here is what you must add to /etc/inittab:

If Monit is used to monitor services that are also started at

boot time (e.g. services started via \s-1SYSV\s0 init rc scripts or via

inittab) then, in some cases, a race condition could occur. That

is; if a service is slow to start, Monit can assume that the

service is not running and possibly try to start it and raise an

alert, while, in fact the service is already about to start or

already in its startup sequence. Please see the \s-1FAQ\s0 for a

solution to this problem.

The Monit control file, \fImonitrc\fR, can include additional

configuration files. This feature helps one to maintain a certain

structure or to place repeating settings into one file. Include

statements can be placed at virtually any spot. The syntax is the

following:

The globstring is any kind of string as defined in \fIglob\fR\|(7). Thus,

need to be embedded into quotes (') or double quotes ("). If the

Any \fIinclude\fR statements in included files are parsed as in the

If the globstring matches several results, the files are included

in a non sorted manner. If you need to rely on a certain order,

you might need to use single \fIinclude\fR statements.

If specified in the control file, Monit will start a Monit daemon

with http support. From a Browser you can then start and stop

services, disable or enable service monitoring as well as view

the status of each service. Also, if Monit logs to its own file,

you can view the content of this logfile in a Browser.

.PP

The status page displayed by the Monit web server is automatically

refreshed with the same poll time set for the monit daemon.

.PP

The Monit web interface is required for \s-1CLI\s0 interface operation, as

all \s-1CLI\s0 commands (such as \*(L"monit status\*(R") are handled by the web

interface.

.IP "\s-1SET HTTPD PORT\s0 <number> \s-1ALLOW\s0 <user:password | IP-address | IP\-range>+ [\s-1ADDRESS\s0 <hostname | IP\-address>] [\s-1SSL\s0 <\s-1ENABLE\s0 | \s-1DISABLE\s0>] [\s-1PEMFILE\s0 <path>] [\s-1CLIENTPEMFILE\s0 <path>] [\s-1ALLOWSELFCERTIFICATION\s0] [\s-1SIGNATURE\s0 <\s-1ENABLE\s0 | \s-1DISABLE\s0>]" 4

.IX Item "SET HTTPD PORT <number> ALLOW <user:password | IP-address | IP-range>+ [ADDRESS <hostname | IP-address>] [SSL <ENABLE | DISABLE>] [PEMFILE <path>] [CLIENTPEMFILE <path>] [ALLOWSELFCERTIFICATION] [SIGNATURE <ENABLE | DISABLE>]"

\&     allow myuser:mypassword

And you can use \fIhttp://localhost:2812/\fR to access the Monit web

interface from a browser.

.PP

\&\fI\s-1PORT\s0\fR option sets the port where Monit should listen. Monit uses

usually port 2812.

.PP

\&\fI\s-1ADDRESS\s0\fR option allows one to make Monit listen on specific interface

only. For example if you \fBdon't\fR want to expose Monit web interface

on external network, bind it to localhost only. Monit will accept

connections on any address by default (if \s-1ADDRESS\s0 option is missing).

\&     allow myuser:mypassword

\&\fI\s-1SSL\s0\fR allows one to enable \s-1SSL\s0 for Monit web interface. Only \s-1TLS\s0 methods

are supported. The \fI\s-1PEMFILE\s0\fR option holds both the server's private key

and certificate. This file should be stored in a safe place on the

filesystem and should have strict permissions, no more than 0700.

Please see \s-1README.SSL\s0 file accompanying the software to get more

information about certificates and generating pem files.

You can use \fIhttps://localhost:2812/\fR to access the Monit web

server over a \s-1SSL\s0 encrypted connection.

OpenSSL \s-1FIPS\s0 is supported, to enable \s-1FIPS\s0 mode (provided your OpenSSL

\&\fI\s-1CLIENTPEMFILE\s0\fR, \fI\s-1ALLOWSELFCERTIFICATION\s0\fR options allow to set

client certificate based authentication. A connecting client has

to provide a certificate known to Monit in order to connect. This

file also needs to have all necessary \s-1CA\s0 certificates. By default

self-signed client certificates are \fBnot\fR allowed. If you want to

use a self signed certificate from a client it has to be allowed

explicitly with the \fI\s-1ALLOWSELFCERTIFICATION\s0\fR statement.

\&\fI\s-1SIGNATURE\s0\fR option can be used to hide Monit version from the

\&\s-1HTTP\s0 response header and error pages.  For example:

Monit web interface access is controlled primarily controlled via the

\&\fB\s-1ALLOW\s0\fR option.

Clients trying to connect to the server but supply the wrong

username and/or password are logged with their ip-address.

See the \fI\s-1CLIENTPEMFILE\s0\fR option above.

The http server maintains an access-control list of hosts and

networks allowed to connect to the server. You can add as many

hosts as you want to, but only hosts with a valid domain name or

its \s-1IP\s0 address are allowed. Networks require a network \s-1IP\s0 and a

netmask to be accepted.

The http server will query a name server to check any hosts

connecting to the server. If a host (client) is trying to connect

to the server, but cannot be found in the access list or cannot

be resolved, the server will shutdown the connection to the

Clients, not mentioned in the allow list, trying to connect to

the server are logged with their ip-address.

Monit supports Basic Authentication schema described in \s-1RFC 2617.\s0

authentication information (username and password) and if

accepted, the server will allow the client access to the

requested document.

The biggest weakness with Basic Authentication is that the

username and password is sent in clear-text (i.e. base64 encoded)

over the network. It is therefor recommended that you do not use

this authentication method unless you run the Monit http server

with \fIssl\fR support. With ssl support it is completely safe to

use Basic Authentication since \fBall\fR http data, including Basic

Monit will use Basic Authentication if an allow statement

contains a username and a password separated with a single ':'

character.  Special characters can be used but the password has

to be quoted.

\&\s-1PAM\s0 is supported on platforms which provide \s-1PAM \s0(such as Linux,

Mac \s-1OS X,\s0 FreeBSD, NetBSD).

where \fIgroup\fR is the group name allowed to access Monit web

interface. Monit uses \s-1PAM\s0 service called \fImonit\fR for \s-1PAM\s0

authentication, see \s-1PAM\s0 manual page for detailed instructions

Sample \s-1PAM\s0 service for Monit on Mac \s-1OS X \s0(store as

And monitrc setting which allows only group admin authenticated

via \s-1PAM\s0 to access the web interface:

Alternatively you can use files in \*(L"htpasswd\*(R" format (one

user:passwd entry per line), like so: \fIallow

[cleartext|crypt|md5] /path [users]\fR. By default cleartext

passwords are read. In case the passwords are digested it is

necessary to specify the cryptographic method. If you do not want

all users in the password file to have access to Monit you can

specify only those users that should have access, in the allow

statement. Otherwise all users are added.

\&      allow hauk:"password"

Monit will raise an event in the following situations:

\& o A file content test found a match 

To get an alert via e\-mail, set the alert target using global \fIset alert\fR

statement (for all services) or using \fIalert\fR statement in the context

of the service entry (for single service).

If an event occurred, Monit will send an alert. There are two kinds of alert

statement: global and local.

.IP "\s-1SET ALERT\s0 mail-address [[\s-1NOT\s0] {event, ...}] [\s-1REMINDER\s0 cycles]" 4

.IX Item "SET ALERT mail-address [[NOT] {event, ...}] [REMINDER cycles]"

will send a default email to the address foo@bar whenever any event occurred on

any service.

\&\fIset alert 'email'\fR statement for each address.

.PP

It is also possible to use the local alert statement in the context of some service

to enable alert for the given service only:

.IP "\s-1ALERT\s0 mail-address [[\s-1NOT\s0] {event, ...}] [\s-1REMINDER\s0 cycles]" 4

.IX Item "ALERT mail-address [[NOT] {event, ...}] [REMINDER cycles]"

.PP

Example:

\&     if failed port 25 protocol http then alert

\&     alert foo@bar

You can combine global and local alert statements. In the case of conflict, the local

alert has precedence and overrides the global statement.

If you only want an alert message sent for certain events, then list them in

the \fI{event, ...}\fR block, e.g.:

You can also set exclude list (negate the list) to send alerts for all events

except those which are listed, by prepending the list with the word \fInot\fR.

For example to receive all alerts except notification about Monit program start

or stop:

List of all possible event types (value from the first column can be used in

the event filter:

\& Event:     | Failure state:            | Success state:              

\& ACTION     | "Action done"             | "Action done"               

\& CHECKSUM   | "Checksum failed"         | "Checksum succeeded"        

\& CONNECTION | "Connection failed"       | "Connection succeeded"      

\& CONTENT    | "Content failed",         | "Content succeeded"

\& DATA       | "Data access error"       | "Data access succeeded"     

\& EXEC       | "Execution failed"        | "Execution succeeded"       

\& FSFLAGS    | "Filesystem flags failed" | "Filesystem flags succeeded"

\& GID        | "GID failed"              | "GID succeeded"             

\& ICMP       | "Ping failed"             | "Ping succeeded"

\& INSTANCE   | "Monit instance changed"  | "Monit instance changed not"

\& INVALID    | "Invalid type"            | "Type succeeded"            

\& NONEXIST   | "Does not exist"          | "Exists"                    

\& PERMISSION | "Permission failed"       | "Permission succeeded"      

\& PID        | "PID failed"              | "PID succeeded"

\& PPID       | "PPID failed"             | "PPID succeeded"

\& RESOURCE   | "Resource limit matched"  | "Resource limit succeeded"  

\& SIZE       | "Size failed"             | "Size succeeded"            

\& STATUS     | "Status failed"           | "Status succeeded"            

\& TIMEOUT    | "Timeout"                 | "Timeout recovery"          

\& TIMESTAMP  | "Timestamp failed"        | "Timestamp succeeded"       

\& UID        | "UID failed"              | "UID succeeded"             

\& UPTIME     | "Uptime failed"           | "Uptime succeeded"

Each alert recipient can have its own filter, for example:

Monit by default sends just \fBone\fR notification if a service failed

and another notification when it recovered. If you want to be notified

that the service is still failed, you can use the reminder option in

the alert statement:

.IP "\s-1SET ALERT\s0 mail-address [\s-1WITH\s0] \s-1REMINDER\s0 [\s-1ON\s0] number [\s-1CYCLES\s0]" 4

.IX Item "SET ALERT mail-address [WITH] REMINDER [ON] number [CYCLES]"

.PP

For example if you want to be notified each tenth cycle if a

service remains in a failed state, you can use:

.PP

.Vb 1

\&  alert foo@bar with reminder on 10 cycles

To suppress alerts for some user and service, add the \s-1NOALERT\s0 statement in the

context of the service which show not generate alerts:

.IP "\s-1NOALERT\s0 mail-address" 4

.IX Item "NOALERT mail-address"

Monit provides a default message format. You can set custom message

format using \fIset mail-format\fR statement:

.IP "\s-1SET\s0 MAIL-FORMAT {mail\-format}" 4

.IX Item "SET MAIL-FORMAT {mail-format}"

The \fIfrom:\fR option is the sender email address.

The \fIsubject:\fR option allows one to set message subject and must be on

only \fIone\fR line.

as needed, but must \fBnot\fR contain the '}' character.

You can set only the option which you want to override. For example

to change sender address only:

The subject and body may contain \f(CW$XYZ\fR variables, which are expanded

by Monit:

.Vb 1

\& A string describing the event that occurred.

.Ve

.Vb 1

\& The service name

.Ve

.Vb 1

\& The current time and date (RFC 822 date style).

.Ve

.Vb 1

\& The name of the host Monit is running on

.Ve

.Vb 1

\& The name of the action which was done by Monit.

.Ve

.Vb 1

\& The description of the error condition

.Ve

defined with a \fIset mailserver\fR statement:

.Vb 3

\& SET MAILSERVER <hostname|ip\-address [PORT number] [USERNAME string] [PASSWORD string] [using SSLAUTO|SSLV2|SSLV3|TLSV1|TLSV11|TLSV12] [CERTMD5 checksum]>, ...

\&                [with TIMEOUT X SECONDS]

\&                [using HOSTNAME hostname]

Multiple mailservers can be set using a comma separated list. If

the list.

(465 for \s-1SSL,\s0 or 25 for \s-1TLS\s0 and non secure connection).

Monit supports \s-1AUTH PLAIN\s0 and \s-1AUTH LOGIN\s0 for \s-1SMTP\s0 authentication.

\& set mailserver mail1.foo.bar, mail2.foo.bar

By default, Monit uses the local host name in \s-1SMTP HELO/EHLO\s0

and in the Message-ID header. You can override it using the

\&\s-1HOSTNAME\s0 option.

If no mail server is available, Monit \fIcan\fR queue events on the

local file-system for retry until mail server recovery.

.PP

If Monit is configured with M/Monit, the event queue provides safe

event store for M/Monit in the case of temporary problems as well.

.PP

The event queue is persistent across Monit restarts and provided

that the back-end filesystem is persistent too, across system

restart as well.

.PP

By default, the queue is disabled and if the alert handler fails,

Monit will simply drop the alert message.

Each service can have \fIstart\fR, \fIstop\fR and \fIrestart\fR methods

which allow Monit to perform corresponding action with the service.

.ie n .IP "<\s-1START\s0 | \s-1STOP\s0 | \s-1RESTART\s0> [\s-1PROGRAM\s0] = ""program"" [[\s-1AS\s0] \s-1UID\s0 <number | string>] [[\s-1AS\s0] \s-1GID\s0 <number | string>] [[\s-1WITH\s0] \s-1TIMEOUT\s0 <number> \s-1SECOND\s0(S)]" 4

.el .IP "<\s-1START\s0 | \s-1STOP\s0 | \s-1RESTART\s0> [\s-1PROGRAM\s0] = ``program'' [[\s-1AS\s0] \s-1UID\s0 <number | string>] [[\s-1AS\s0] \s-1GID\s0 <number | string>] [[\s-1WITH\s0] \s-1TIMEOUT\s0 <number> \s-1SECOND\s0(S)]" 4

.IX Item "<START | STOP | RESTART> [PROGRAM] = program [[AS] UID <number | string>] [[AS] GID <number | string>] [[WITH] TIMEOUT <number> SECOND(S)]"

.PP

If the \fIprogram\fR is shell script it must begin with \f(CW\*(C`#!\*(C'\fR and

The \fIprogram\fR must be executable (for example mode 0755).

\& stop = "/bin/bash \-c \*(Aqkill \-s SIGTERM \`cat /var/run/myproc.pid\`\*(Aq"

\&   start program = "/usr/local/mmonit/bin/mmonit \-d" as uid "mmonit" and gid "mmonit"

In the case of process check, Monit waits up to 30 seconds for the

start/stop action to finish by checking the process table. You can

override the action timeout using the \fI\s-1TIMEOUT\s0\fR option.

Services are checked in regular intervals given by the \fIset

daemon n\fR statement. Checks are performed in the same order as

they are written in the \fI.monitrc\fR file, except if dependencies

are setup between services, in which case the services hierarchy

may alternate the order of the checks.

It is possible to modify the check schedule using the \fIevery\fR

.IP "1. custom interval based on poll cycle length multiple" 4

.IX Item "1. custom interval based on poll cycle length multiple"

.Vb 1

\&      EVERY [number] CYCLES

.Ve

.IP "2. test schedule based on cron-style string" 4

.IX Item "2. test schedule based on cron-style string"

.Vb 1

\&      EVERY [cron]

.Ve

.IP "3. do-not-test schedule based on cron-style string" 4

.IX Item "3. do-not-test schedule based on cron-style string"

.Vb 1

\&      NOT EVERY [cron]

\& Name:        | Allowed values:            | Special characters:              

\&              | 9AM. Note that range is from time1 until and

\&              | including time2. That is, from 8AM and until

\&   every 2 cycles

\& check program checkOracleDatabase with

\&       path /var/monit/programs/checkoracle.pl

\&   every "* 8\-19 * * 1\-5"

Example 3: Do not run the check in the backup window on 

\&   not every "* 0\-3 * * 0"

The current test scheduler is poll cycle based. When Monit starts

testing and the service test is constraint with the \fIevery cron\fR

statement, it checks whether the current time match the

cron-string pattern. If it does, the test is done, otherwise it

is skipped. The cron specification thus does not guarantee when

exactly the test will run \- that depends on the default poll time

and the length of the testing cycle. In other words, we cannot

guarantee that Monit will run on a specific time. Therefor we

minimum a range, e..g. 0\-15. \fBNever\fR use a specific minute as

Monit may not run on that minute.

We will address this limitation in a future release and convert

the test scheduler from serial polling into a parallel

non-blocking scheduler where checks are guaranteed to run on time

and with seconds resolution.

the \fIstatus\fR and \fIsummary\fR commands don't support the \-g

Service can be added to multiple groups by adding group statement

multiple times:

In \fIactive\fR mode, Monit will pro-actively monitor a service and

in case of problems Monit will raise alerts and/or restart the

service. Active mode is the default mode.

.PP

In \fIpassive\fR mode, Monit will passively monitor a service and

will raise alerts, but will \fBnot\fR try to fix a problem.

.PP

In \fImanual\fR mode, Monit will enter \fIactive\fR mode \fBonly\fR if a

of Monit control. The manual mode can be used to build simple