[Top][All Lists]

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

Re: P2 depends on P1. "Start P1" will "Start P2"? Wrong?

From: Jack Martin
Subject: Re: P2 depends on P1. "Start P1" will "Start P2"? Wrong?
Date: Sun, 1 Mar 2015 21:11:17 -0500

Thanks for that detailed answer. We will be sure to unmonitor the group first if we need to exercise this case of starting independent process P1 on some server without starting the dependent process P2.


On Sat, Feb 28, 2015 at 10:21 AM, Jan-Henrik Haukeland <address@hidden> wrote:
Service dependencies is described here, Dependencies in Monit goes both ways, in a way and was created for a more tightly coupled dependency chain. The primary example which dependencies was created for is a setup like, a database server (P1 in your example) and an application server with a connection pool to the database server (P2). Now if the database server goes down, open (TCP) connections in the app-server’s connection pool will no longer work when the database server is started again, so the app-server needs to be restarted as well. 10 years ago this would often be necessary. Today, a modern connection pool might/should be able to recover a database restart and restarting the app-server and connection pool is overkill.

A simpler dependency version is wanted and on our roadmap with explicit “is dependent by” or “depends on” relations which just describes the start order _and_ a check to see if dependent services are running and no attempt to restart "is dependent" by services.

Ps. Apropos start order, if no dependencies are used, services will be started in the order they are listed in the .monitrc file.

> On 28 Feb 2015, at 02:37, Jack Martin <address@hidden> wrote:
> My question is about startup and dependencies. Suppose P2 depends on P1. It makes sense that if you use "monit start P2", then monit should start P1 before it starts P2. However, running "monit start P1" will *also* cause P2 to be started despite P2 not being a dependency of P1. This seems like an error. Is there any chance that behavior could be changed?
> This interferes with some production deployment code, and results in our needing to unmonitor a related group of processes before manually starting processes since starting P1 will start P2 (unintentionally).
> Thanks,
> Jack

To unsubscribe:

reply via email to

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