Exec implemented!

[Jan-Henrik Haukeland]

I took a stab at implementing the exec functionality today. This was a
harder nut to crack than I thought :) The implementation is not
perfect but the best I could come up with now.

Enclosed to this mail is a short diagram explaining the
implementation, so here I'm just going to explain what has been
added. Please, also check the CVS check-in patches accompanying this
mail, shortly.

1) The timestamp statement is extended to check for timestamp
   changes as well. Now you can use the timestamp statement like this
   also:

     if timestamp /etc/passwd was changed then..

2) The action part of both a resource and timestamp statement is
   extended to take an exec statement. The exec sub-statement has the
   same expression power as the start/stop statement (it uses the same
   rules in the parser). This means that a program to execute can take
   a number of arguments and even start with a certain UID/GID.
  
   An example of an exec statement for timestamp may look like this
   (this particular example is good for testing):

      if timestamp /tmp/file was changed 
       then exec "/usr/X11R6/bin/xmessage -display :0 timestamp event"
       as UID hauk and with GID hauk

   Here is one for a resource statement:

        if mem > 100 Mb then exec "/usr/local/apache/bin/http restart"

3) I have also added an extra feature to the parser. Now every program
   mentioned in a start/stop/exec statement is checked in the parser
   if they actually exist. If a program does not exist, the parser
   aborts with an error message. This is much better than the
   possibility that monit should try to start the program and then
   only fail.

4) TODO:

   a) I have not checked this with the various device statements but
      it should work without changes.

   b) I have not tested this extensively. Could others also please test.

   c) I have only added the exec statement to timestamp and resource
      statements but it could be added to other statements as well,
      for instance the checksum statement and port statement, maybe
      also to the timeout statement? If you look in the parser you can
      see that this is not hard to do.

   d) Do we need to make it possible to use the various MONIT_XXX
      variables as parameters to the exec program and then substitute
      them with real values before they are executed? Like:
          exec "$MONIT_PROGRAM $MONIT_DATE"
      (where $MONIT_PROGRAM will be replaced with e.g.:
      /usr/local/apache/bin/http). It would probably be usefull for
      $MONIT_PROGRAM but for the other variables they will anyway be
      available as environments variables. Opinions?

   e) I must update the documentation in monit.pod but I'm going on a
      short vacation tomorrow morning and will sail for a couple of
      days and wanted to check in this in case the boat should sink :)
      so I hope you will forgive this violation of the project
      standard that documentation should always match the latest
      code base. I promise, I'll fix it as soon as I get back.

   f) If you are not on a vacation could you please check the code. As
      I said, I'm not overly satisfied with the implementation and if
      you can find a better way it would be very nice. It's not that
      it is bad, but the association between an event, an action and
      the program to execute upon a EXEC action is very weak and may
      be error prone on usage.

Ps. I have been thinking and rethinking about the monit 4.0 release --
I think that implementing Martin's language proposal could take some
time and we have done lot's of changes and bugfixes to the current
codebase. What do you think about freezing what we have now and do an
intermediate 3.3 release in a short while and take the language
changes in a 4.0 release later this year? I would feel a little more
confident taking on the language changes if we could freeze and
stabilize the current code base with a release and make sure that it
works properly first. What do you think?

Design.jpg
Description: Design.jpg

-- 
Jan-Henrik Haukeland