[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: monit "check program" reap interval

From: Jan-Henrik Haukeland
Subject: Re: monit "check program" reap interval
Date: Fri, 15 Jun 2012 08:01:03 +0200

On Jun 15, 2012, at 3:21 AM, Leif Gustafson wrote:

> Thanks for the response.  The main issue I have with the behavior is
> that it seems as if you don't get alerted in a timely fashion *if* you
> skip cycles, and it seems to get worse the more cycles you skip.  Say I
> configure a script to run once per day (because the script performs an
> expensive operation that can't be run often)... I configure it to run
> every 1440 cycles (or use the new cron-like functionality).  In this
> scenario, I wouldn't be notified of problems until the process has been
> reaped (approximately one day later).  At least, that's the issue that I
> seem to be up against.
> The new event-based engine sounds fantastic.  Until that happens, it
> would be nice to be able to either control when the child gets reaped or
> at least check once per cycle (still honoring the default or specified
> timeout) so that we can still deal with problems in a timely fashion.

If you have a service you want to check once in a time frame.  Well, yes that 
is a problem with the current poll cycle model. You _can_ work around it as 

1) You need to modify the script Monit checks as follows or create a wrapper 
script for your program; At the start of the script have it check for a 
lock-file. If the file does not exist run the program, then create the file. If 
the file exist and was created within 24 hours, just have the program return 0 
without starting its job. Otherwise run the job and before exit touch the 
lock-file so the next time the script is called it will just return 0 directly.

2) Configure the check in Monit to use the every statement within a poll-cycle 
range. Assume you check each 2 min, and want to run the script/program every 
monday at 5 min past 9 AM use something like

 check program X with
       path /some/path/to/
 every "0-10 9 * * 1" ...

The above will ensure that the actual job is run once at or close to the wanted 
time. It is far from perfect, but should work

reply via email to

[Prev in Thread] Current Thread [Next in Thread]