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. Perhaps a different question to ask is whether this case is useful without changing the svcs -x behaviour with regard to degraded. > 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. Indeed, and has already met with opposition. (And I see the point of Nico's opposition.) Again, I think the question worth asking is whether the improvement suggested by this case's original spec is valuable enough on its own, and whether it precludes changing or augmenting existing svcs -x behaviour with respect to degraded. I think the improvement is valuable on its own, as svcs -x as defined today is a bit hostile to scripting due to the lack of exit code. I don't think this case precludes changing svcs -x in the future (either through default behaviour or an additional option) to also include degraded services. Is there anyone that disagrees with those assertions? liane
