Martin Pala <address@hidden> writes:
In addition to the solution described in my previous mail, it is
possible to revert to old behavior, e.g. in the case of error, set
(optionally) the expected test value to current erroneous value and
stop monitoring by default. Monitoring stop must be handed by all
dependants in both cases (previous and this proposal).
In such case however, it could be probably better to drop IF-THEN
scheme for checksum, permission, uid and gid statements, because the
behavior will be fixed/predicted and different from other
statements/checks => instead of current:
if failed checksum then stop
write again:
checksum
I like better first proposal - it provides more power and from my
personal point of view it is more clean and consistent with the
language.
I agree, absolutely. Having checksum together with an action is
flexible and powerful. The way checksum is now with IF-THEN is the
best way. There is a "problem" with stop and restart, but I think we
can keep the current implementation and simply document us out of the
problem :)
- Take the situation where checksum is used with security in mind and
used to watch a file for changes. In this case we simply recomend that
the user only use the alert action. This way, it will almost work as
the old checksum statement, apart from that the program is still
monitored. This means that restart or stop may be called in the
corresponding process service entry, but this is a minor problem since
an alert has been sent, which is the most important part.
- If checksum is used to monitor a configuration file for changes then
every action (i.e. exec, alert, restart or stop) may be used. The only
thing I will add is that if there was a change, the old checksum is
replaced with the new (like we did with; "if timestamp was changed"),
this way monit will only do the action once and not for every cycle.
Agree?