On 4/28/2015 10:50 AM, bougyman wrote:
Well at least we're talking the same language now, though reversing
"parent/child" is disconcerting to my OCD.
Sorry if the terminology is "reversed".
Here's the current version of run.sh, with dependency support baked
in:
https://bitbucket.org/avery_payne/supervision-scripts/src/b8383ed5aaa1f6d848c1a85e6216e59ba98c3440/sv/.run/run.sh?at=default
That's a gnarley run script. It's as big as a lot of sysvinit or OpenRC
scripts I've seen. One of the reasons I like daemontools style package
management is my run scripts are usually less than 10 lines.
This was my thought, as well. It adds a level of complexity we try to
avoid in our run scripts.
It also seems to me that there is less typing involved in individual
run scripts than the
individual things that have to be configured for this script. If on
goal of this
abstraction is to minimize mistakes, adding more moving parts to edit
doesn't seem to
work towards that goal.
Currently there are the following sections, in sequence:
1. shunt stderr to stdout for logging purposes
2. shunt supporting symlinks into the $PATH so that tools are "called"
correctly. This is critical to supporting more than just a single
framework; all of the programs referenced in .bin are actually symlinks
that point to the correct program to run. See the .bin/use-* scripts
for details.
3. if a definition is "broken" in some way, then immediately write a
message to the log and abort the run.
4. if dependency handling is enabled, then process dependencies.
Otherwise, just skip the entire thing. By default, dependencies are
disabled; this means ./run scripts behave as if they have no dependency
support.
4a. should dependency handling fail, log the failing child in the
parent's log, and abort the run.
5. figure out if user or group IDs are in used, and define them.
6. figure out if a run state directory is needed. If so, set it up.
7. start the daemon.
