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.