On Tue, Mar 11, 2008 at 08:03:58AM -0700, Liane Praza wrote:
> Mark Martin wrote:
>> On Thu, Feb 28, 2008 at 11:19 AM, Liane Praza <liane.praza at sun.com
>> <mailto: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.
>
> I believe so, but I'm not the one that made the request.
>
>> This might also mean adding degraded state support to svc.startd (or it
>> may not).
>
> It does not require that. Degraded is defined, and already used by another
> restarter. Making svc.startd (or any other restarter) implement that state
> is not required for svcs to change its handling of that state.
>
>> 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).
>
> Ugh. That's what I'm not at all convinced of. You'd be both changing the
> default behaviour of svcs -x to print more services (IIRC Nico was opposed
> to this), and ending up with some kind of weird exit codes.
>
> I believe Ceri suggested a new option to include degraded services, which
> I'm not necessarily opposed to (though seems a little weird), and if
> pursued would require vetting with the SMF community. I guess that would
> solve the exit code stuff, but I really don't believe that the PSARC
> aliases are the place to iterate through design proposals, so won't go
> further.
Well, I don't really care either way; I didn't make the original
request.
I assumed that the anticipated use case of "svcs -xq" would be something
along the lines of:
if [ svcs -xq ]; then
# all is well, do X
X()
else
# something is broken, do Y and notify an admin
Y()
crybaby()
fi
and it occurred to me that "services exist in degraded status" is not
the same as "all is well". If that opinion is somehow completely wrong
(and I still don't really understand why, but that's besides the point)
then there's nothing to do here.
Ceri
--
That must be wonderful! I don't understand it at all.
-- Moliere
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080311/2a315eb3/attachment.bin>
