[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question on the dependency of processes
From: |
Martin Pala |
Subject: |
Re: Question on the dependency of processes |
Date: |
Thu, 14 Apr 2005 22:28:19 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 |
Yiwen Jiang wrote:
Hi there,
I sent a couple of emails to the general mailing list under the same
subject line, but got busy in some other things. I finally got some time
to look at monit again. And I am in the process of building a test case
as requested, and will keep you posted on the results.
However, I noticed that in the 'Dependencies' section of the monit
manual, there was an example of process start/stop/crashed scenario. In
the example, there was not a mentioning of multiple process crash
scenarioes. In fact, in the multiple crash/exit scenario, the start up
sequence is different from a clean start scenario. I am starting to
wonder if what I'm using monit for is indeed its design intent.
Using the following server startup as an example:
WEB-SERVER -> APPLICATION-SERVER -> DATABASE -> FILESYSTEM
(a) (b) (c) (d)
If b does not run, monit will "first stop a then start b and finally
start a again". Cool.
The behaviour changes quite a bit if both a and b are found to be not
running by monit:
Because of the way monit is implemented, a will be started first, and
then b. This is in conflicting with the 'If no servers are running'
behaviour, where as b is started before a.
No.
In the case that both processes are stopped, two cases are possible
depending on the rank of service during testing cycle ('a' before 'b' or
vice versa):
1.) monit tested 'a' before 'b':
It will first try to START 'b' and then RESTART 'a'
2.) monit tested 'b' before 'a':
It will first try to STOP 'a', then RESTART 'b', then START 'a'
While servers should be designed to accommodate the disappearing of its
own communication parties, there are applications that do not behave
like this. Instead, they count on process dependencies framework (i.e.
restarting dependant processes) to ensure the proper re-establishment of
communication once the most depending process is restarted.
Is monit designed to handle cases like this? Or is there a pre-requisite
where if process a depends on process b, and if b is down (crashed,
killed, etc), a will remain up and running?
In the case that 'b' crashed, monit will stop 'a' ... see above
Martin