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 <[email protected]> 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 <[email protected]> > Sent: 1/15/2015 9:11 PM > To: [email protected] > 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. ;) >
