Re: Proposal: change connection tests statement

[Martin Pala]

I though about it, i don't agree with these changes. Here is my -1 for 
both points, bellow are my arguments, but please don't take my vote as 
'veto' (it is just my point of view ;)

Jan-Henrik Haukeland wrote:

> 1) 
>
> In the current monit version it is possible to write a connection test
> in a process entry as shown below:
>
> check process xinetd with pidfile /var/run/xinetd.pid
>       start program = "...."
>       stop program = "..."
>       alert address@hidden
> -->    if failed port 631 then alert
>
> I suggest that this is removed in the next release and that a connection
> test is only allowed in a check-host entry. As the example below
> illustrate the depend statement can be used to express the same thing.
> There are 3 reasons I want to remove connection tests from a process
> entry, a) Logically it does not belong in the process entry b) it's
> easier in the documentation to explain connection test if it's in one
> place c) the code will be better. 
>
> Unless I get a veto vote on this I'm going to change the code when I get
> time. Yes, it will break backward compatibility but it will also make
> the control file language cleaner. We could deprecate connection tests
> in a check process entry and allow it in a few new versions of monit or
> invalidate now and print an error? Personally I would like to invalidate
> it now with an explanatory error message.
I think we should keep the connection test support for local process. I 
think it is just one property of the process and it is correct to define 
all its characteristics in one container. For example the other socket 
type (unix socket) is not possible to test via 'check host' statement, 
but logicaly addresses the same functionality of the process, which is 
requests handling (though via other transport channel).

> 2) 
>
> In addition I also propose that we change the connection statement and
> remove host name from it. Since we have a check-host statement it is
> redundant and it sort of breaks the logic of a check host entry in that
> you can specify another host than the one checked. I.e. this is legal
>
> check host redhat with address www.redhat.com
>    if failed host debian.org port 80 ...
>    if failed port 80 ....
>
> In other words I suggest that it's not possible to specify the host in
> the if-test and that the above is illegal. This means that if you want
> to test another host you must create a new check host entry.
>
>  
I think it is useful to have support for host sprecification in 
connection statement. The reason is that you can use 'check host' 
statement as test for remote process with virtual hosts support. For 
example:

check host myhost with address 192.168.1.1
 if failed host www.alias1.com port 80 ...
 if failed host www.alias2.com port 80 ...

The characteristics of both these virtual hosts are given by the same 
backend process => if you involve some "hard" action (such as restart) 
it will affect the other service as well. Because the service will most 
probably have the same state, there could be race condition. For these 
reasons i think that it is one subject for testing. The proposed syntax 
may brake the test to two parts, but the relationship here is broken 
(there's no dependency - it is the same object). The split syntax can 
complicate the control file too - some servers has hundreds of virtual 
hosts, in current syntax this means one check host statement - in new 
syntax this will require same number of check host statements as virtual 
hosts.


Martin