Re: Feature request for config file checking?

[Rick Robino]

On Wednesday, June 11, 2003, at 11:13  AM, Jan-Henrik Haukeland wrote:

> 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:
> > > [..] 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.

This works great - if there is anything to add I might like to see 
current resource values "CPUUSAGE", "MEMUSAGE", "MEMK-BYTE", "LOADAVG", 
etc., also passed...  perhaps all current values associated 
specifically (or globally) to process, including monitrc loaded.  Maybe 
a `df -k`-like picture of the local disk(s)... The more the better for 
help decision making, automatic or otherwise.

Setting some environment variables for any script that gets run is an 
_excellent_ idea... it's beyond praise.  This is the feature I (now) 
most look forward to, if it does get adopted.

> > If some primitive conditional expression becomes part of monit's
> > [..]
>
> 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 :-)

... thank you, and the other readers for your tolerance <wink>.  To 
kick this around just a little more:

It may be worth considering the case that such a high price for 
extending along these lines signifies a warning rahter than a hurdle.  
Without waiting for the feature to be supported explicitly one can 
already duplicate the proposed behavior by using groups, timeout and 
adding some state intelligence to the start/stop scripts (which are 
arbitrary).  Adding the 'run command' statement as proposed above 
already affords a substantial amount of granularity to the command 
writer, and if the environment variables were there one would have 
enough input to completely and comfortably write simple triggers for 
various scenarios.

[random thought: would it be more reasonable to treat each check 
<resource> like the current check process statement, with an 
(arbitrary) start and stop script?]

As an example of how some env vars might be handy in a real-world 
situation: for one reason or another (an admin or some vendor 
procedure) will overwrite our modified apachectl script in /usr/sbin - 
ours often keeps the pid in a location other than SERVER_ROOT/logs or 
/var/run because because it doesn't run as root and we can't loosen the 
mode on /var/run.  monit sees that httpd has changed its checksum and 
then runs the start script (apachectl), removing the old pid.  The new 
apachectl of course doesn't see the old pid and does the wrong thing 
because there is another apache instance already running, and monit now 
does not see a pid file at all - etc, etc, etc.

So in my start script I check a slew of cases keeping many of the same 
data the env vars would provide and save results in a file, taking care 
to finish everything under the monit check period... if I could 
instantly know [[ -z $MONIT_PROGRAM_PID ]] my handlers can become much 
simpler and robust and more effective.  Similarly hairy interdependency 
issues among groups, clamav/spamd/sendmail for example, would also 
benefit from seeing what monit thinks the situation is.

Before anyone says anything about the quoted apache setup, I know there 
are many other ways to skin that cat - it's a policy thing with a 
particular client.  Enough on this subject from me for a while  8-)

--
Richard T. Robino


--
Richard T. Robino
Internet Systems Architect
Wave Division Consulting
http://www.wavedivision.com/~rrobino/