On Tue, Apr 28, 2015 at 12:31 PM, Steve Litt <slitt_at_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
Received on Tue Apr 28 2015 - 17:50:40 UTC