[Top][All Lists]

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

Re: Feature request for config file checking?

From: Rick Robino
Subject: Re: Feature request for config file checking?
Date: Wed, 11 Jun 2003 13:09:38 -0700

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/
 Then $MONIT_PROGRAM_PID will contain the pid found in

 $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

reply via email to

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