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?