On Tue, Mar 11, 2008 at 11:06 AM, Ceri Davies <ceri at submonkey.net> wrote:
> On Tue, Mar 11, 2008 at 08:03:58AM -0700, Liane Praza wrote:
> > 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
>
This was my assumption as well.
>
> 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.
Ok, so here's the modified documentation:
DESCRIPTION
The fourth form explains the states of service instances.
For each argument, a block of human-readable text is
displayed which explains what state the service is in, and
why it is in that state. With no arguments, problematic ser-
vices are described.
+ If the optional -q is provided in the fourth form, the command
+ produces no human-readable text and simply returns an error
+ code indicative of the existence of problematic services. With
+ this flag, an error code of 3 indicates services exist that are in
+ a maintenance state or are blocking other enabled services,
+ whereas an error code of 0 indicates no services in the
+ maintenance state.
EXIT STATUS
+
+ 3 Services exist in problematic state.
Ceri, as to your point about (service_degraded == all_is_well), that's out
of scope for this case. I'll file a bug for svcs -x showing degraded state
and we can hash that at a later date.
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080311/97555394/attachment.html>