/[monit]/monit/monit.pod
ViewVC logotype

Diff of /monit/monit.pod

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.125 by hauk, Fri Oct 17 17:54:26 2003 UTC revision 1.126 by hauk, Wed Oct 22 22:34:14 2003 UTC
# Line 1373  is as follows (keywords are in capital a Line 1373  is as follows (keywords are in capital a
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
# Line 2745  B<F</etc/init.d/monit-node1>> Line 2745  B<F</etc/init.d/monit-node1>>
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    
# Line 2758  The active node fails, the second takes Line 2757  The active node fails, the second takes
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

Legend:
Removed from v.1.125  
changed lines
  Added in v.1.126

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26