On Wed, 7 Jan 2015 14:25:28 -0800
Avery Payne <avery.p.payne_at_gmail.com> wrote:
> On Wed, Jan 7, 2015 at 7:23 AM, Steve Litt <slitt_at_troubleshooters.com>
> wrote:
> >
> > I'm pretty sure this conforms to James' preference (and mine
> > probably) that it be done in the config and not in the init program.
> >
> > To satisfy Laurent's preference, everything but the exec cron -f
> > could be commented out, and if the user wants to use this, he/she
> > can uncomment all the rest. Or your run script writing program
> > could have an option to write the dependencies, or not.
> >
>
> I've pretty much settled on a system-wide switch in sv/.env (which in
> the scripts will show up as ../.env). The switch will, by default,
> follow Laruent's behavior of "naive launching", ie. no dependencies
> are up, missing dependencies cause failures,
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?
This is all pretty cool, Avery! Currently, my best guess is that
eventually my daily driver computer will be initted by runit (with
Epoch as a backup, should I bork my runit). It sounds like what you're
doing will ease runit config by an order of magnitude.
> and the admin must check
> logging for notifications. Enabling the feature would be as simple as
>
> echo "1" > /etc/sv/.env/NEEDS_ENABLED
>
> ...and every new service launch would receive it. You could also
> force-reload with a restart command. Without the flag, the entire
> chunk of dependency code is bypassed and the launch continues "as
> normal".
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?
>
> The goal is the same but the emphasis has changed. This will be
> considered a fall-back feature for those systems that do not have
> such a tool available, or have constraints that force the continued
> use of a shell launcher. It is the option of last resort, and while
> I think I can make it work fairly consistently, it will come with
> some warnings in the wiki. For Laurent, he wouldn't even need to
> lift a finger - it fully complies with his desires out of the box. ;-)
>
> As new tools emerge in the future, I will be able to write a shunt
> into the script that detects the tool and uses it instead of the
> built-in scripted support. This will allow Laurent's work to be
> integrated without messing anything up, so the behavior will be the
> same, but implemented differently.
Now THAT'S Unix at work!
>
> Finally, with regard to the up vs actually running issue, I'm not even
> going to try and address it due to the race conditions involved. The
> best I will manage is to first issue the up, then do a service check
> to confirm that it didn't die upon launch, which for a majority (but
> not all) cases should suffice. Yes, there are still race conditions,
> but that is fine - I'm falling back to the original model of "service
> fails continually until it succeeds", which means a silently-failed
> "child" dependency that was missed by the "check" command will still
> cause the "parent" script to fail, because the daemon itself will
> fail. It is a crude form of graceful failure. So the supervisor
> starts the parent again...and again...until the truant dependency is
> up and running, at which point it will bring the parent up. 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.
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.
>
> Right now the biggest problem is handling all of the service tool
> calls. They all have the same grammar, (tool) (command) (service
> name), so I can script that easily. Getting the tools to show up as
> the correct command and command option is something else, and I'm
> working on a way to wedge it into the use-* scripts so that the tools
> are set up out of the box all at the same time. This will create
> $SVCTOOL, and a set of $CMDDOWN, $CMDUP, $CMDCHECK, etc. that will be
> used in the scripts. **Once that is done I can fully test the rest
> of the dependency concept and get it fleshed out.** If anyone wants
> to see it, email me directly and I'll pass it along, but there's not
> much to look at.
If I read the preceding correctly, you're making service tool calls for
runit, s6, perp and nosh grammatically identical. Are you doing that so
that your run scripts can invoke the init-agnostic commands, so you
just have one version of your scripts?
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 can help with the documentation.
SteveT
Steve Litt *
http://www.troubleshooters.com/
Troubleshooting Training * Human Performance
Received on Thu Jan 08 2015 - 17:23:23 UTC