Re: [PATCH] Running an external script with EXEC on a timeout

[Martin Pala]

Patrick Burns wrote:
> On Wed, 9 Mar 2005 23:42:24 +0100, "Jan-Henrik Haukeland"
> <address@hidden> said:
>
> > Patrick, if you care to build on your own patch and go one extra mile 
> > and implement this feature described here: 
> > http://www.tildeslash.com/monit/doc/next.php#20 I'm sure we will 
> > happily accept this patch. What do you think, will you give it a stab?
>
>
> Yes, I had thought about implementing that one. If no-one else is
> writing it, I'm sure I could give it a try.
>
> So the syntax is:
>     if X EVENT within Y cycles then ACTION
>
> What will "event" mean? Does it make sense to have something like:
>     check file su with path /bin/su
>         if changed size then exec "/usr/sbin/restore_backup.sh"
>         if 3 changes within 5 cycles then exec "/sbin/ifconfig eth0
>         down"
>
> E.g. something at the resource level. If the file changes then do some
> action, if the file changes too often then do another action.
>
> There is already something similar for resource testing:
>     if cpu is greater than 50% for 5 cycles then restart
>
> Am I on the right track?

The 'EVENT' is event engine related.

Each testing rule generates event id in the case of state change. 
Depending on the current state the polarity is either 'failed' or 
'passed'. You can find current list of basic event id list in the 
event.h file:

#define EVENT_NULL         0x0
#define EVENT_CHECKSUM     0x1
#define EVENT_RESOURCE     0x2
#define EVENT_TIMEOUT      0x4
#define EVENT_TIMESTAMP    0x8
#define EVENT_SIZE         0x10
#define EVENT_CONNECTION   0x20
#define EVENT_PERMISSION   0x40
#define EVENT_UID          0x80
#define EVENT_GID          0x100
#define EVENT_NONEXIST     0x200
#define EVENT_INVALID      0x400
#define EVENT_DATA         0x800
#define EVENT_EXEC         0x1000
#define EVENT_CHANGED      0x2000
#define EVENT_ICMP         0x4000

The event polarity (failed/passed) is described in Event_T structure/class.

The event engine provides general handler for these events. The idea for 
the event ratio dependant action stack (triggers) is, that the event 
engine will allow to:

- count particular events in the state context
- handle events by matching the current state to the appropriate action rule

The mentioned syntax is just tentative idea - it is possible that there 
is better way how to do it.

Martin