Re: Exec implemented!

[Jan-Henrik Haukeland]

Martin Pala <address@hidden> writes:

> Control language clean-up is possible, e.g. allow all "file" related
> tests (like 'checksum', 'timestamp', etc.) in just "file" service
> type. These test then could be simplified - the 'path' part could be
> removed, because the path will be specified in 'file service'
> definition. For example replace :
>
>    checksum /usr/local/apache/bin/httpd and expect the sum
>    8f7f419955cefa0b33a2ba316cba3659
>
> with
>
>    checksum and expect the sum 8f7f419955cefa0b33a2ba316cba3659
>
>
> More complex example:
>
> ---
> check process apache with path /usr/local/apache/logs/httpd.pid
>    start program = "/etc/init.d/httpd start"
>    stop program = "/etc/init.d/httpd stop"
>    depends on apache_rc
>    depends on apache_binary
>    depends on apache_conf
>    ...
>
>  check file apache_rc with path /etc/init.d/httpd
>    checksum and expect the sum 1a6d429254cafa8b34c2bb317cba2118
>    if timestamp changed the alert
>    perm 755 # just example
>
>  check file apache_binary with path /usr/local/apache/bin/httpd
>    checksum and expect the sum 8f7f419955cefa0b33a2ba316cba3659
>    if timestamp changed the alert
>    perm 755 # just example
>
>  check file apache_conf with path /etc/httpd/conf/httpd.conf
>    if timestamp changed the reload
>    size < 10 MB
>    perm 755 # just example
> ---

This looks very nice, but..

> If any of these files is removed, action is taken by monit.
>
> Though such configuration is clean, logical and object oriented, i
> think it is probably usefull to have present shortcut and allow to
> define file related test in other service types as well.

the checksum test should be kept for process-services because it's
directly connected to the process in that a process is not checked
anymore by monit if any of its programs was changed. BTW, I haven't
tested the above configuration, will it actually work with the current
monit? If so, it's cooool :)

> What do you think? Shall we restrict the language in this sense?

It's tempting but I think it will be difficult to nullify a
process-service using this. (By nullifying I mean that the
process-service is not checked anymore in case of a checksum error,
which was the original reason for introducing checksum in the first
place).

> I'm +1 for freezing and release, but i think the major version number
> should be probably upgraded (mark it as 4.0), because of big changes
> in model and codebase (events), move from process oriented monitoring
> to more general monitoring (devices, files, directories), etc. Anyway
> extensive testing is needed before release, but because of changes
> this release can behave very different from previous releases and
> there can be hidden bugs (and version 3.3 seems less dangerous than
> 4.0). I generally prefer slow versioning, but n this case i'm -1 to
> mark it as 3.3.

Good argumentation, and I have no problem agreeing that we should make
it a 4.0 release based on this argumentation.

-- 
Jan-Henrik Haukeland