RE: first round of optional dependency support

From: James Powell <james4591_at_hotmail.com>
Date: Thu, 15 Jan 2015 21:16:12 -0800

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<mailto:avery.p.payne_at_gmail.com>
Sent: ‎1/‎15/‎2015 9:11 PM
To: supervision_at_list.skarnet.org<mailto: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:16:12 UTC