[Top][All Lists]

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

Re: Proposal: change connection tests statement

From: Martin Pala
Subject: Re: Proposal: change connection tests statement
Date: Mon, 13 Dec 2004 15:58:07 +0100
User-agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020921 Netscape/7.0

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.


reply via email to

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