On Thu, Jan 8, 2015 at 9:23 AM, Steve Litt <[email protected]> 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.
