Re: event ratio dependant actions implementation

[Martin Pala]

Good point :) However, in such case it will be needed to implement the 
possibility to add rules for some actions which are currently 
implicit/hardcoded.

For example when the process doesn't exist, there is currently no rule 
which allows to specify the action for such case - the implicit action 
is to restart the service. The present timeout statement in this case 
allows to unmonitor the service ...

The solution could be to implement statements for implicitly handled 
events too, such as (currently implicit):

  if failed existence then restart

the new statement can also allow to try other recovery actions based on 
the error ratio (such as try some other recovery technique):

--8<--
 check process homeless with pidfile /var/run/forest.pid
  start program = "/etc/init.d/salvation start"
  stop program = "/etc/init.d/salvation stop"
  if failed existence then restart
  if failed existence 3 times within 5 cycles then exec '/hard/recovery'
  if failed existence for 5 cycles then unmonitor
--8<--


The implicit actions are currently added in parser's createservice():

--8<--
  /* Initialize general event handlers */
  addeventaction(&(current)->action_DATA,     ACTION_ALERT, 
ACTION_ALERT);
  addeventaction(&(current)->action_EXEC,     ACTION_ALERT, 
ACTION_ALERT);
  addeventaction(&(current)->action_INVALID,  ACTION_RESTART, 
ACTION_ALERT);
  addeventaction(&(current)->action_NONEXIST, ACTION_RESTART, 
ACTION_ALERT);
  addeventaction(&(current)->action_TIMEOUT,  ACTION_UNMONITOR, 
ACTION_ALERT);
  addeventaction(&(current)->action_PID,      ACTION_ALERT, 
ACTION_IGNORE);
  addeventaction(&(current)->action_PPID,     ACTION_ALERT, 
ACTION_IGNORE);
--8<--

The PID and PPID already has optional statement implemented ('if failed 
pid then ...'), these implicit actions are added when the statement was 
not specified.

Most probably the implementation will be quite straightforward (similar 
to PID/PPID) ... the infrastructure is ready, just p.y parser extension 
is probably needed - maybe in some future release? :)


Martin


Jan-Henrik Haukeland wrote:
> Very nice work Martin! I'll check it out later in detail, but just  want 
> to add that this new function render the old timeout statement  
> redundant and I vote for making timeout depreciated   with a warning  in 
> the parser when used. Many are using it, so we can probably not  remove 
> it before a 5.x release if we should be nice about it, which  we should.