1373 |
IF FAILED ICMP TYPE ECHO [WITH] [TIMEOUT number SECONDS] |
IF FAILED ICMP TYPE ECHO [WITH] [TIMEOUT number SECONDS] |
1374 |
THEN action |
THEN action |
1375 |
|
|
1376 |
The rules for action and timeout is the same as those mentioned |
The rules for action and timeout are the same as those mentioned |
1377 |
above in the CONNECTION TESTING section. An icmp ping test is |
above in the CONNECTION TESTING section. An icmp ping test is |
1378 |
very useful for testing if a host is up, before testing ports at |
useful for testing if a host is up, before testing ports at the |
1379 |
the host. If an icmp ping test is used in a check host entry, |
host. If an icmp ping test is used in a check host entry, this |
1380 |
this test is run first and if the ping test should fail we assume |
test is run first and if the ping test should fail we assume that |
1381 |
that the connection to the host is down and monit does I<not> |
the connection to the host is down and monit does I<not> continue |
1382 |
continue to test any port connections. Here's an example: |
to test any ports. Here's an example: |
1383 |
|
|
1384 |
check host xyzzy with address xyzzy.org |
check host xyzzy with address xyzzy.org |
1385 |
if failed icmp type echo with timeout 15 seconds |
if failed icmp type echo with timeout 15 seconds |
2745 |
|
|
2746 |
As mentioned elsewhere, monit save its state to a state file. If |
As mentioned elsewhere, monit save its state to a state file. If |
2747 |
the monit process should die, upon restart monit will read its |
the monit process should die, upon restart monit will read its |
2748 |
last known state from the state file. This can be a problem if |
last known state from this file. This can be a problem if monit |
2749 |
monit is used in a cluster, as illustrate in this common |
is used in a cluster, as illustrate in this scenario: |
|
scenario: |
|
2750 |
|
|
2751 |
=over 4 |
=over 4 |
2752 |
|
|
2757 |
=item 2 |
=item 2 |
2758 |
|
|
2759 |
After a reboot, the failed node comes back, monit read its state |
After a reboot, the failed node comes back, monit read its state |
2760 |
file and starts all the services (even manual ones) as they were |
file and start all the services (even manual ones) as they were |
2761 |
running before the failure. This is a problem because services |
running before the failure. This is a problem because services |
2762 |
will now run on both nodes. |
will now run on both nodes. |
2763 |
|
|
2764 |
=back |
=back |
2765 |
|
|
2766 |
The solution to this problem is to remove the monit.state file in |
The solution to this problem is to remove the monit.state file in |
2767 |
a rc-script called at boot time and before monit is started. Or |
a rc-script called at boot time and before monit is started. |
|
as one user did; save the monit state file on a ram disk. |
|
2768 |
|
|
2769 |
|
|
2770 |
=head1 FILES |
=head1 FILES |