On 4/21/2015 3:08 PM, Buck Evan wrote:
On Tue, Apr 21, 2015 at 2:46 PM, Avery Payne <avery.p.pa...@gmail.com
<mailto:avery.p.pa...@gmail.com>> wrote:
Alternatively, are there general-purpose practices for
breaking this kind
of dependency?
Strange as it sounds, renaming the child definition of a
dependency chain (which typically translates into the directory
name of the defintion) seems to be a regular issue. Changing the
name of the definition typically causes various "links" to break,
causing the parent service to be unable to locate its children by
name at start-up.
Ah, I just realized you misunderstood me. You understood "breaking
dependencies" to mean "the dependant system no longer works" where
what I meant was "the dependency is no longer relevant".
With regard to practice or policy, I can only speak to my own project.
I try to stick with "minimum feasible assumption" when designing
things. In the case of the run script handling dependencies, it only
assumes that the child failed for reasons known only to the child, and
therefore the parent will abort out and eventually spawn-loop. Prior to
exiting the script, a message is left for the systems administrator
about which child failed, so that they can at least see why the parent
refused to start. Beyond that, I try not to assume too much.
If the dependency is no longer relevant, then that is a small issue -
the ./needs directory holds the names of all the child processes that
are needed, and if the child will fail because it's broken / moved /
uninstalled / picked up its marbles and went home, then the parent will
simply continue to fail to start, until the child's name is removed from
the ./needs directory. Again, you'll see a recorded message in the
parent log about the child causing the failure, but not much more than
that. It can be easily fixed by simply removing the child symlink in
./needs, which will cause the parent to "forget" about the child. This
possibility should be documented somewhere in the project, and I know I
haven't done so yet. Thanks for bringing it up, I'll try to get to it soon.
