Re: Exec implemented!

[Jan-Henrik Haukeland]

Christian Hopp <address@hidden> writes:

> On Sun, 20 Jul 2003, Jan-Henrik Haukeland wrote:
>
> Moin!

Hey! :-)

>> 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.
>
> (...)
>
> What if the program is deleted while monit runtime?  Should monit
> test, just before running it.  If failed, send a message?

The main reason for testing if a program exist or not in the parser is
to catch typically typing errors and warn about those before monit
starts. But, yes, it does not cost much to do the same test at the
start of spawn.c as well, although it is sort of covered already since
if a program was removed later, it will be catched in spawn.c since
the execve() will return an error. [This is logged now, but it may
look like we will have to close the log _before_ the execve since the
descriptor is keept open for child processes, see the latest mail in
monit-general about "Closing files".]

> I did some simple tests with it... it looks okay.

Great, if you dare, maybe you could use this in production to test it
even more?

>>    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.
>
> For checksum and port it sounds reasonable.  But I don't really see
> the reason for timeout.

Yeah, I agree, and let's keep the exec statement only for the resource
and timestamp statement to make it easy for now.


>>    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?
*
>
> If it is anyways just useful for one variable, it might be too much
> unnecessary code for it.

My thoughs also. Well, maybe a few other variables would be useful,
but since they exist as env. variables I'm not going to add this then.

> I find it a bit confusing to have the alert event handler in alert.c
> and not int event.c.  Better, have an interface handle_alert_event in
> event.c and put any event specific code in it and call a maillist
> worker in alert.c. Possible?

Good point and sure, it's possible to factor out the more specific
event code from handle_alert_event like you suggest and put it in
event.c. It may make the code clearer. The same argument you gave can
also be used for code in validate.c. I think there are still some code
that should be taken out from validate.c and put into the various
event handlers.


>> 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?
>
> What feature would be still pending for 3.3?

Not much actually, but here are a few items I can think of. (Please
all of you, add to this list if you now of other issues):

1) The most important is probably to cleanup the documentation in the
monit.pod file and align it with all the changes done in the code
base. Personally, I also feel that we can do more to structure and
improve this documentation. I'll use some time this week to see what I
can do, and all suggestions for improvements are very welcome.

2) It would be great if Rory would find time to test monit on the many
different machines and OS'es he has access to, particularly OS X and
FreeBSD I think.

3) With shame, I have to admitt that I haven't had time to test all
the new fancy device code submitted by Martin. I would very much like
to test this more before a release and I'm planning on doing it, this
week. What about you, Christian, have you had time to test this
functionality?

4) Fix the "Closing files" bug report sent to the monit-general list. 

5) I need to cleanup stuff around the new exec statement and timestamp
extension. That is, fix the monit -v debug info and info printed in
the web-interface.

6) Factor obvious event code (in alert.c and in validate.c) into event
handlers as mentioned above. Do you have time to give it a stab?

7) I plan to fix socket.c so it can create TCP|UPD|UNIX sockets and
thus remove create_generic_socket() from the code and from net.c. This
way, socket.c will be a simple fasade against parts of net.c and we
can hide more of the gory details. The protocol interface will also be
easier; Instead of obtaining a Port_T object in the function we can
send a Socket_T object and the protocol code can use the methods in
the socket.c class to write and read from the socket. E.g. the
check_pop function and other check functions will get this signature:

  int check_pop(Socket_T s) 

8) Add the rdate protocol patch we got from Francois Isabelle.




-- 
Jan-Henrik Haukeland