Re: Feature request for config file checking?

[Jan-Henrik Haukeland]

Rick Robino <address@hidden> writes:

> On Tuesday, June 10, 2003, at 11:11  PM, Mark Ferlatte wrote:
> 
> > I want to be able to run any script.  Simply a:
> >
> > check timestamp foo.conf if changed then run "/etc/init.d/foo restart"
> >
> > solves all of these problems easily.
> >
> >> "timestamp" remains flexible so that we can AND an alert, execute
> >> restart script or whatever besides/rather-than just sending a signal?
> >
> > Just run a script that sends kill -SIG.  No need for monit to have
> > to add more special case parsing.

Agree, a generic solution like this is good and may reduce the need to
expand the monit control file language (for now). Anyway, I'm planing
on implementing the ability to run arbitary programs for the alert
statement and may hopefully reuse code for the timestamp stuff as well.

> So - I also agree with this idea:  + for the ability to run arbitrary
> commands (whatever the syntax).  The command could be fed the subject
> of the expression - pid, timestamp, timeout, etc, as first and only
> argument.  At least the pid.

Sure. But I think the best (easiest) is to pass this information in
environment variables to the script/program. That is, every script
executed by monit can expect certain environment variables to be
present. For instance (are there more you can think off?):

 $MONIT_PROGRAM_PID = The associated CHECK program's pid. For example
 if the CHECK statement is:
  check apache with pidfile /usr/local/apache/logs/httpd.pid
 Then $MONIT_PROGRAM_PID will contain the pid found in httpd.pid.

 $MONIT_$EVENT = A string describing the event that occured. The
 values are fixed and are, `restarted', `timed out', `stopped',
 'checksum error` and `timestamp' (for timestamp changes)

 $MONIT_PROGRAM = The program entry name in monitrc. I.e. apache from
 the example above.

 $MONIT_DATE = The current time and date (C time style).

 $MONIT_HOST = The hostname monit is running on.


> If some primitive conditional expression becomes part of monit's
> vocabulary as proposed in J-H's RFD it may also be worth discussing
> the notion of checking the return code of the proposed arbitrary
> command, so as to branch to other statements if the first command did
> not exit 0.  For one, it may alleviate the temptation to make a single
> command allowed cover all cases by itself outside of monit, possibly
> to the point of duplicating some of monit's own functionality.  For
> two, it would satisfy generically many more complicated needs than
> executing one command that may only fail timeout*times and eventually
> leave the service down.
>
> Of course this may constitute serious featurecreep, and checking the
> return value requires monit to wait for the command to terminate
> (potential for problems), but it is a natural complement to the
> ability to run scripts other than start/stop and in light of other
> proposed syntax changes.
> 
> Being able to run a command besides start or stop on a per-check basis
> like timestamp is a big win already, maybe there is no reason for
> further conditional processing - and it could be that I have even
> misunderstood the "if" proposal on the table in thinking that checks
> can have individual responses.  Maybe if timeouts could be expressed
> in a way where monit would execute the arbitrary command if timeout n
> is reached the same problem would be solved without as much fuzz.
> 
> I don't know, but if the movement is towards more complex
> functionality then this sort of granular control is something I would
> like to see.  Just a thought.  Apologies for extending the scope of
> this subject to that of the general control file language.

Thank you for your thoughts on this. I agree with you that it would be
a good thing to be able to branch out and do different actions based
on the return value from executing a remote program. This does imply a
more programmatic approach to the control file language (i.e. the
ability to program or script) which again may imply introductions of
variables and suchs and much work with the parser and usage of a
symbol table, type checks, ADT's.

In the future this may very well be a good evolution of the control
file language (as hinted in, in the recent RFD) and interesting for us
developers to implement. But for the upcomming release I think the
best thing to do is to make the 'run command' statement a *fire and
forget action*. At least if the next release should come out in a week
or two :-)


-- 
Jan-Henrik Haukeland