James Carlson wrote: > It's not an orderly shutdown if you request to have a service with > hard dependencies shut down and you don't also ask to have those > dependencies shut down as well, is it?
It depends on whether you consider it obvious that they are implicitly shut down. I'll grant that that's not a foregone conclusion, and perhaps your "-f" / "-r" answer is a better one, to make the administrator intent explicit. > I'll argue that anything that sents the same set of flags to the same > state ought to be time-invariant, if it's going to be comprehensible > to mere mortals. I am not quite sure that I follow your point. How you get from point A to point B can be quite important. > So, run the scenario in the forwards order: if you enable those > dependent services without ever having enabled the required dependency > enabled, then the dependent services end up in "offline" state without > ever having run in any order. Yes. > I think that if we allow a dependency in the middle of the tree to be > yanked out arbitrarily, we should end up in the same state as if we'd > enabled everything but skipped over that one entity. That means > getting them into "offline" state in either case. Yes. (But there is a question as to *how* you get there.) > That's also the same as if we had failed this dependency, and we thus > had to tear everything down after the fact -- basically ignoring the > reverse-order "requirement." Yes. > At this point, the question I'm asking is whether you should be able > to enter "offline" state in both orders or just one. I think entering > it in just one order (failure-like semantics) makes more sense. Here's an analogy: You can get the system from fully running to powered off in two ways: 1) Shut down all of the services in an orderly fashion, and then remove power. 2) Remove power. They both end up at the same point - system is powered off - so they're equivalent, right? Why do we bother with all of this orderly-shutdown stuff, when we have to handle the powerfail case anyway? > It even allows for more obvious testing scenarios by just disabling a > required service to make sure that failure handling "works" (whatever > that means ;-}). Now, indeed, there's a lot to be said for designing a system so that the way that you turn it off is simply to remove power, but for a bunch of reasons we don't usually do that.