On Tue, Apr 28, 2015 at 12:31 PM, Steve Litt <sl...@troubleshooters.com> wrote:
> Good! I was about to ask the definitions of parent and child, but the > preceding makes it clear. Well at least we're talking the same language now, though reversing "parent/child" is disconcerting to my OCD. >> >> 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. > And, as you said in a past email, having a run-once capability without > insane kludges would be nice, and as you said in another past email, > it's not enough to test for the child service to be "up" according to > runit, but it must pass a test to indicate the process itself is > functional. I've been doing that ever since you mentioned it. When run-once is necessary we decide per-service whether it's a true one-shot (networking, etc) or a spooky background daemon that we may want to watch. If the latter the ./run script contains our (probably polling) supervisor, if it's a networking type job, we end with exec /bin/pause (part of runit-void). For the 'making sure it is actually up', a ./check script suffices. Tj