2008/159 svcs -xq

[Mark Martin]

On Thu, Feb 28, 2008 at 11:19 AM, Liane Praza <liane.praza at sun.com> wrote:

> Nicolas Williams wrote:
> > On Wed, Feb 27, 2008 at 05:06:45PM -0800, Liane Praza wrote:
> >> Nicolas Williams wrote:
> >>> I guess we still have time, before degraded is actually implemented,
> to
> >>> resolve the shared configuration issue.  Or you could have another
> svcs
> >>> option to control whether degraded -> error.
> >> svcs -x already considers degraded to be a "service that is enabled but
> >> not running".  This case doesn't change that fact.
> >
> > Huh?  Since what build?  I don't see that with fairly recent bits
> > (degraded shows up as "online").
>
> svc.startd isn't using the degraded state.  This is a bug.  inetd does
> use the degraded state.
>
> But, that's orthogonal to the svcs -x behaviour, which I was wrong about.
>
> "svcs -x <fmri>" does attempt to diagnose why a service is in degraded,
> which I misread last night to say that it will display degraded services
> in its unadorned "svcs -x" invocation.  That's not true.  My apologies.
>
> This means Ceri's request is a new one.  It falls out of the scope of
> the current definition of svcs -x:
>
>                          Without   arguments,   the   -x   option
>                          explains the states of services which:
>
>                              o    are enabled, but are  not  run-
>                                   ning.
>
>                              o    are preventing another  enabled
>                                   service from running.


Ok, so just so I have a correct understanding, what is really desired here
is the ability for svcs -x to now also delineate "degraded' services as well
as the 2 cases which it is already enumerating.  This might also mean adding
degraded state support to svc.startd (or it may not).  If this additional
state is enumerated, then there should be an additional exit code for it
(and presumably yet a third for services existing in both state buckets).

I'll have to do some digging as to how much effort this will add, but adding
degraded state checking to svcs seems at this point like a candidate for new
CR (and possibly another integration case refactoring svcs -x[q] to support
it).


>
>
> I'm going to turn this into a fasttrack (expiring on 6 March), to let
> Mark consider whether it's in-scope and appropriate to address this new
> request as part of this case.  (And re-validate any updates with the SMF
> community.)


I'll ask at tomorrows PSARC meeting for another week to research this and
either amend this case with the new functionality, or open a new CR and
join() them.   My current thinking is that implementing and integrating the
new degraded state enumeration as a later refactoring case won't jive with
the commitment level indicated in this case.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080304/2ed35d82/attachment.html>