On Thu, Jan 8, 2015 at 9:23 AM, Steve Litt <slitt_at_troubleshooters.com>
wrote:
>
> I'm having trouble understanding exactly what you're saying. You mean
> the executable being daemonized fails, by itself, because a service it
> needs isn't there, right? You *don't* mean that the init itself fails,
> right?
>
Both correct.
> I'm not sure what you're saying. Are you saying that the dependency
> code is in the runscript, but within an IF statement that checks
> for ../env/NEEDS_ENABLED?
>
Correct. If the switch, which is a data value in a file, is zero, it
simply skips all of the dependency stuff with a giant if-then wrapper. At
least, that's the plan. I won't know until I can get to it.
> > Like I
> > said, this will be a fall-back feature, and it will have minor
> > annoyances or issues.
>
> Yes. If I'm understanding you correctly, you're only going so far in
> determinint "really up", because otherwise writing a one size fits all
> services thing starts getting way too complicated.
>
Correct. I'm taking an approach that has "the minimum needed to make
things work correctly."
>
> I was looking at runit docs yesterday before my Init System
> presentation, and learned that I'm supposed to put my own "Really Up"
> code in a script called ./check.
>
Also correct, although I'm trying to only do ./check scripts where
absolutely needed, such as the ypbind situation. Otherwise, the check
usually looks at "is the child PID still around".
> If I read the preceding correctly, you're making service tool calls for
> runit, s6, perp and nosh grammatically identical.
Correct.
> Are you doing that so
> that your run scripts can invoke the init-agnostic commands, so you
> just have one version of your scripts?
>
Exactly correct. This how I am able to turn the bulk of the definitions
into templates. ./run files in the definition directories are little more
than symlinks back to a script in ../.run, which means...write once, use a
whole lot. :) It's also the reason that features are slow in coming - I
have to be very, very careful about interactions.
>
> However you end up doing the preceding, I think it's essential to
> thoroughly document it, complete with examples. I think that the
> additional layer of indirection might be skipped by those not fully
> aware of the purpose.
>
I just haven't gotten around to this part, sorry.
>
> I can help with the documentation.
>
https://bitbucket.org/avery_payne/supervision-scripts
or
https://github.com/apayne/supervision-scripts
Feel free to clone, change, and send a pull request.
Received on Thu Jan 08 2015 - 20:10:34 UTC