Process Dependency?

From: Avery Payne <avery.p.payne_at_gmail.com>
Date: Thu, 30 Oct 2014 11:43:24 -0700

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 "see" the
./needs directory the same way it would "see" the ./log directory. Each
entry in ./needs is a symlink to an existing (service) directory, so
everything needed to start (dependency) is already available. The
(service) launcher would notify its *parent* that it wants those launched,
and it would be the parent's responsibility to bring up each process
entry. For s6 the parent would be s6-svscan, for runit it would be
runsvdir. During this time the launcher simply waits until it is signaled
to either proceed, or to abort and clean up. Once all dependency entries
are up, the parent would signal that the launcher can proceed to start
./run. There isn't much in the way of state-tracking beyond the signals,
and the symlinks reduce the requirement for more memory. The existing
mechanisms for checking processes remain in place, and can be re-used to
ensure that a dependent process didn't die before the ./run script turns
over control to (service). Just about all ./run scripts remain as-is and
even if they "launch a dependency" they continue to work (because it's
already launched).

What are the hidden issues that I'm not aware of?
Received on Thu Oct 30 2014 - 18:43:24 UTC