thoughts on rudimentary dependency handling

From: Avery Payne <avery.p.payne_at_gmail.com>
Date: Tue, 6 Jan 2015 08:29:13 -0800

I'm asking for some input. I obviously have limitations with regard to
what I can do for all three frameworks in the project, so if this seems
limited in scope, you're right, it is. My thoughts are:

* incorporate it into the base template. I'm trying to minimize the number
of templates around, otherwise, why bother if there are 100's of
templates? I might as well write all of them as unique stand-alone
scripts, and that defeats the purpose of templates in the first place.
* implement a ./wants directory. This would have symlinks to any
definitions that would be nice to have running, but are not required. For
instance, smbd runs fine by itself, but it would be nice to have nmbd and
winbind also running as well; if they don't start, it won't block smbd from
starting.
* implement a ./needs directory. This would have symlinks to any
definitions that would be required to run before the main definition can
run. For instance, Debian's version of lightdm requires that dbus be
running, or it will abort. Should a ./needs not be met, the current
definition will receive a ./down file, write out a message indicating what
service blocked it from starting, and then will send a "down service" to
itself.
* implement a ./conflicts directory. Any service that would conflict with
either the primary definition, or any definitions in ./needs or ./wants
would be symlinked here. There would be a simple probe that asks "is the
service up"? If so, it simply aborts the current definition and warns the
administrator about the conflict.

The ./needs and ./wants are pretty straightfoward, and are easily
implemented. I don't see any real issues with them.

For ./conflict I do not want to force the conflicting service down - there
may be other services depending on it, and bringing down the conflicting
service may cause problems.

Here's where I need input. The ./conflict concept is somewhat racy - you
could in theory have a service starting while it is being probed, the probe
coming first (and indicating the service as down), and then the service
start. I'm not sure there's an easy way to trap for this condition. Worst
case, I jettison the ./conflicts directory altogether and let services
"naturally fail" due to file name or port number collisions, etc.

Suggestions on how to better improve ./conflicts? Or should it be
abandoned within the context of how these scripts are currently written?
Keep in mind, these scripts try not to assume too much, and that includes C
source code, etc., so I'm not looking to write a special program that
handles race conditions like this.
Received on Tue Jan 06 2015 - 16:29:13 UTC