Re: first round of optional dependency support

From: Avery Payne <avery.p.payne_at_gmail.com>
Date: Thu, 15 Jan 2015 21:44:11 -0800

Depends on what you call fail-safe.

If you mean "will only run a service if all dependencies met", then yes.
The current mode is to log the dependency failure and exit the script. The
service will of course run-loop until fixed; this isn't far from the
current non-dependency behavior anyways. The emitted warnings in the log
should be descriptive enough to diagnose the problem and remedy it.

If you mean "attempt run regardless of dependencies", then no. In my eyes,
that would be a ./wants directory, and I debated doing that as well. I
figured, ./wants is a variant of ./needs, so I should get ./needs right
first. Once I know ./needs is stable, I can adapt it, removing a lot of
the failure code, and it turns into ./wants, i.e. "attempt to start the
dependency, but if it doesn't start, don't worry about it, keep going"


On Thu, Jan 15, 2015 at 9:16 PM, James Powell <james4591_at_hotmail.com> wrote:

> Service scripts often need a lot of setup code before the actual daemon
> is executed. My question is, does it provide a fail-safe solution to
> dependency trees?
>
> Shutdown is only an issue if you need a finish script, otherwise the
> service supervisor will execute the kill signal and bring things down.
>
> Sent from my Windows Phone
> ------------------------------
> From: Avery Payne <avery.p.payne_at_gmail.com>
> Sent: ‎1/‎15/‎2015 9:11 PM
> To: supervision_at_list.skarnet.org
> Subject: first round of optional dependency support
>
> Ok, admittedly I'm excited because it works.
>
> The High Points:
>
> + It works (ok, yeah, it took me long enough.)
> + Framework-neutral grammar for bringing services up and checking them, no
> case-switches needed
> + Uses symlinks (of course) to declare dependencies in a tidy ./needs
> directory
> + Can do chain dependencies, where A needs B, B needs C, C starts as a
> consequence of starting A
> + Chain dependencies are naive, having no concept of each other beyond what
> is in their ./needs directory, so you do NOT need to declare the kitchen
> sink when setting up ./needs
> + Is entirely optional, it is off by default, so you get the existing
> behavior until enabled
> + Simple activation, you enable it by writing a "1" to a file
> + Smart enough to notice missing definitions or /service entries, a script
> will fail until fixed
>
> The So-So Points:
>
> ~ Framework grammar makes the working assumption that it follows a
> tool-command-service format. This might be a problem for future frameworks
> that require tool-service-command or other grammars.
> ~ Some distro maintainers may have situations where they compile out
> something that will be defined in a ./needs, or may compile in something
> that is missing from ./needs; this mismatch will bring tears, but for now,
> I am assuming that things are "sane enough" that these inter-dependencies
> will remain intact.
> ~ I'm not happy with handling of ./env settings, it could have been cleaner
> ~ Oversight of dependencies is based on the assumption that the supervisor
> for the dependency will keep the service propped up and running.
> ~ Once enabled, you need to start or restart services. It doesn't affect
> running services.
> ~ Currently starting a scripts sends the commands up, then check. Maybe it
> should do check, then up, then check? That feels wrong - at what point
> does it turn into turtles all the way down?
>
> The Low Points:
>
> - Not true dependency management. It only tackles start-up, not shut-down,
> and won't monitor a chain of dependencies for failures or restarts.
> - Enormous code bloat. By the time I finished with the bulk of exception
> handling, I felt like I ran a marathon...twice. The resulting script is
> *multiple* times the size of the others.
> - The number of dependent commands needed in user-space to run the script
> has gone up....way up. Every additional user-space tool included is
> another "does your install have X" that ultimately limits things -
> especially embedded devices. Did I mention bloat earlier?
> - Way too many failure tests, which means...way too many failure paths.
> This makes testing much harder.
> - There's a bug (or two) lurking in there, my gut tells me so....
> - Relative pathing is fine for a static install inside of /etc, but what
> happens when users try to spawn off their own user-controlled services? I
> smell a security hole in the making...
>
> The Plan:
>
> This will become a part of avahi-daemon and forked-daapd definitions, but
> disabled by default. From everyone else's perspectives, it will function
> like it always did, until enabled. With sv/.env/ENABLE_NEEDS set to 1, for
> example, a launch of forked-daapd will bring up avahi-daemon, and
> avahi-daemon will bring up dbus.
>
> Constructive criticism welcome. I ask that Laurent leaves his flamethrower
> at home - the urge to burn it with fire to purify the project may be
> strong. ;)
>
Received on Fri Jan 16 2015 - 05:44:11 UTC