|
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 |
Jan-Henrik Haukeland wrote:
1)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 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 oneplace 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 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: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.
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
[Prev in Thread] | Current Thread | [Next in Thread] |