.)
The design issues I see are:
* First and foremost, as always, services can be more than processes.
Your design would only handle dependencies between long-lived processes;
those are easy to solve and are not the annoying part of service
management, iow I don't think process dependency is worth
and are not the annoying part of service
management, iow I don't think process dependency is worth tackling
per se. Dependencies between long-lived processes and machine state that
is *not* represented by long-lived processes is the critical part of
dependency management, and what supervision frameworks
A message was dropped...passing it along as part of the discussion
-- Forwarded message --
From: Casper Ti. Vector caspervec...@gmail.com
Date: Fri, Oct 31, 2014 at 3:37 AM
Subject: Re: Process Dependency?
To: Avery Payne avery.p.pa...@gmail.com
Sorry, but I just found that I did
would only handle dependencies between long-lived processes;
those are easy to solve and are not the annoying part of service
management, iow I don't think process dependency is worth tackling
per se. Dependencies between long-lived processes and machine state that
is *not* represented
Le 31/10/2014 21:04, Avery Payne a écrit :
The reason I was attempting to tackle process dependencies is
actually driven by dbus friends. I've stumbled on many modern
processes that need to have A, and possibly B, running before they
launch. Of course, you are right, in the perspective that
I know that most process management tools look at having the script do the
heavy lifting (or at least carry the load by calling other tools) when
trying to bring up dependencies. Couldn't we just have a (service)/needs
directory?
The idea is that the launch program (s6-supervise or runsv) would
