Re: first round of optional dependency support

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

I just realized what you might have meant. Sorry, it's late where I'm at.

Ok, so you want a guarantee that if A starts B and B starts C, that A will
only be up with B and C. There is a weak guarantee here; B will only start
fully when C starts, so A will block B if B is waiting for C. So yes,
although it's not a firm guarantee. If you go back and read the discussion
from a little while back, you'll see there are limitations to this and it's
an option "of last resort".

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 - 07:21:43 UTC