Re: Monit 4 enhancement requests

[Jan-Henrik Haukeland]

Martin Pala <address@hidden> writes:

> ad. 1.) ICMP ping support - already scheduled, i will look on it. I
> think i can start the implementation next week.

I think I have read someplace about a fping.c file that you can use? 
If not, simply use the enclosed file. It's a ping-of-death program
with ip-spoofing, I stumbeled over a while ago and hacked a bit (nb!
this is not my work). You should probably remove the spoofing :-) and
you need to read response from the server. Combining this with net.c:
check_udp_socket() should do the trick. (To spoof replace the
xxx.xxx.xxx.xxx string with the ip-address, but to use this program as
is it is, is of course a bad idea)

> ad. 2.) IPv6 support - it could be interesting (but not for me for
> this moment)

Agree, this is something we can wait with until IPv6 has become more
common.

> ad. 3.) daemontools - it could be good to test it and add the hint to
> documentation. I can do it.

Great. BTW, Klaus Alexander Seistrup sent me a notice later and told
me that my suggestion will not work:

| Actually, I think this should already be possible (I do not use
| daemontools so I cannot test it). If monit has a tty, which it
| has if it was started with the -I switch, then monit will print
| log messages *both* to the logfile/syslog and too the tty's stderr.

because isatty() is false when monit is run under daemontools. Instead
he simply used this hack in log_log:

replacing:

        nolog:
        if (Run.have_tty) {
with:
        nolog:
        if (Run.have_tty || Run.init) {

This might even be enough with a bit more code since env.c guarantee
that the std file descriptors should be open, altough they may go to
/dev/null, so a check on this is probably necessary.

> ad. 4.) alert limitation on x of y cycles - this could be usefull too,
> but in such case we need to discuss timeout statement relationship.
*
> The syntax can be commonized to, for example:
>
> IF x {event[, event]...} WITHIN y CYCLES THEN {timeout|alert}
>
> => you can choose for each type of event ratio when to alert or when
> to timeout. Event is specification of the event type (such as restart,
> start, timestamp, etc.) If you will not specify alert ratio for
> particular events (for example restart) or at all, by default monit
> will send alert every cycle, which is equivalent to:
>
> if 1 restart within 1 cycle then alert
*
> If you will not specify timeout statement, you will receive the alert
> either every cycle or as limited by above alert condition statement.
>
> What do you think?

I think this is a good and general proposal, (I think you suggested
something like this before also :)

Christian's suggestion; "alert [once] emailaddr". is also good. Maybe
we should combine both suggestions, since they fix different parts of
the problem and together is should be enough.

t.c
Description: t.c

-- 
Jan-Henrik Haukeland