James Carlson wrote:
> Jordan Brown writes:
>>> 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.
>
> I agree that the order of operations along the path is important.
>
> I'm saying that I don't think you should end up in a different stable
> (long-term) state if the same set of flags are set. In other words,
> this:
>
> svcadm disable foo/top-one
> svcadm enable foo/a-depends-on-top-one
> svcadm enable foo/b-depends-on-top-one
>
> should result in the same long-term state as:
>
> svcadm enable foo/a-depends-on-top-one
> svcadm enable foo/b-depends-on-top-one
> svcadm disable foo/top-one
Er... sure. You don't specify the previous state for the three
services, so I'm not following. Perhaps I'm just being thick.
For both the current behavior (shut down the specified service, then
shut down the dependencies) and the proposed behavior (shut down the
dependencies, then shut down the specified service), the end result of
that sequence is
a enabled, not running due to dependency
b enabled, not running due to dependency
top-one disabled, not running.
With the -r and -f flags that you proposed, if the three services
started out enabled and running, in both cases the "disable" would fail
because there are dependent services running.
Now perhaps you are saying that with the -r and -f flags, with A, B, and
top-one enabled and running, the sequence
svcadm disable first-one
svcadm disable a
svcadm disable b
would yield a different state than the sequence
svcadm disable a
svcadm disable b
svcadm disable first-one
because in the first case the first disable would fail due to dependencies.
But hmm. Sometimes I don't *want* "disable -r" functionality. I want
to disable that service, and cleanly shut down its dependencies, but I
don't want to *disable* them... they should come back when I re-enable
the specified service.
That might mean using disable -f, but then we would be back to the
question of whether that shuts down the dependencies in dependency
order, or shuts down the specified service and treats it as a service
failure with respect to the others.
>>> 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:
>
> I'm not so sure that analogy works too well. One of the clear
> side-effects of losing power is that RAM is cleared out and in-flight
> disk transactions are gone.
>
> That's not true of the state of the dependent services after a service
> failure. Those services still get a chance to shut themselves down in
> an "orderly" way, if they're still able to do that.
If you terminate the depended-upon service, from the point of view of
its dependencies it has failed. Any transactions they might be in the
middle of are in trouble, sessions are lost, and so on. It's a failure
case for them.
That's not the same as terminating them first, so that they have the
opportunity to shut down the sessions from *their* end, when it's
convenient for them.
> As long as we have to handle the case where a dependency goes away
> (and the service has to go into "offline" state), I think we ought to
> be consistent about handling that case.
Why should we handle administrative shutdown of a depended-upon service
differently from failure? Because we can, because we can offer the
dependent services an opportunity to clean up before the rug is yanked
out from under them.
>> 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?
>
> Not the same; all services lose state on the power-off case, not just
> the one that failed.
Er... if you terminate a server, the clients lose session state.
