Re: [developer] Review - 15665 svc:/network/loopback exits successfully even if it fails

["Joshua M. Clulow" <josh@sysmgr.org>]

On Wed, 31 Jul 2024 at 02:45, Peter Tribble <peter.tribble@gmail.com> wrote:
> On Tue, Jul 30, 2024 at 11:46 PM Gordon Ross <gordon.w.ross@gmail.com> wrote:
>> Optional dependency does that in SMF, right?
> Well no, that's a rather different case. That is the "I don't care if it's enabled or not,
> but if it is I'll have a hard dependency on it".

That's not what "optional_all" does.  As per smf(7):

  optional_all

    Satisfied if the cited services are running (online or
    degraded) or do not run without administrative action
    (disabled, maintenance, not present, or offline
    waiting for dependencies which do not start without
    administrative action).

Note, most critically, if a service is in the maintenance state, it
will not run without administrative action.  This allows a dependency
with the "optional_all" group to proceed with starting up.

> What we're after here is the "I do care that it's enabled, and must run after it, but I'm
> prepared to live with errors".

That's what "optional_all" does.  It's effectively just for startup
sequencing; i.e., "as long as you believe you're going to start the
service, I'll wait, but if that changes just start me straight away".

I think the important thing to recognise is that dependencies aren't
considering what's marked enabled or disabled, they're considering the
_state_ of services and potentially the _next state_ for services in
transition (e.g., being started or stopped).  It's a subtle but
important distinction because there _is_ a state called "disabled" as
well, but that's separate from whether the service is marked as being
enabled or disabled by the administrator.  After you mark a service as
disabled, it might not hit the "disabled" state for quite some time,
depending on what state it was in to begin with.

The keen reader will note that "not present" is also not a state, but
it's treated like one in the mental model: it's the state implicitly
assumed for services we don't appear to have on the system.  Obviously
services that do not exist will not be able to run without some
administrative action either.

I agree that the degraded state is interesting in the limit, but I do
not believe it is necessary to implement more of it merely to get the
behaviour you're asking for here.


Cheers.

-- 
Joshua M. Clulow
http://blog.sysmgr.org