[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal: change connection tests statement

From: rory
Subject: Re: Proposal: change connection tests statement
Date: Mon, 13 Dec 2004 08:45:07 -0800 (PST)

I agree with Martin. (-1)

> 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:
>>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/
>>       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).
>>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
>>    if failed host 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
>   if failed host port 80 ...
>   if failed host 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
> --
> To unsubscribe:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]