2008/159 svcs -xq

[Garrett D'Amore]

FYI, I believe Mark is now a full intern, so modulo possible 
considerations about his ability to access the tools (which I've offered 
to help with), I believe he can submit his own cases.

Mark, should you require assistance (remote fingers as it were) in 
submitting new ARC cases, please don't hesitate to ask me for help.

    -- Garrett

Liane Praza wrote:
> I'm submitting this case on behalf of Mark Martin.  I've made it
> an Automatic approval, as it is adding an option to svcs which is
> already in identical use in another already ARCed command (svcprop).
>
> If there are concerns, we'll happily turn this into a fasttrack and
> let the discussion run its course.
>
> liane
>
> ---
>
> svcs -xq
> Mark Martin
> 27 February 2008
>
> 1. Summary
>
>   An unnamed customer has requested an enhancement to svcs -x output
>   which produces no output but would set the error level to 0 if there
>   are no services in a problematic state and a non-zero result if
>   svcs -x would actually produce an output.  This enhancement provides
>   an additional -q flag to to the svcs command which quietens svcs -x
>   output and allows easier integration with admin scripts which may only
>   need to know if there are either 0 or at least one service in a
>   problematic state and do not want to parse svcs -x output.
>
>   It should be noted that this optional flag would emulate the similar
>   -q flag in svcprop, a related SMF command.
>
> 2. Interface table
>
>   Interface                   Stability
>   ---------                   ---------
>   svcs -xq (q option letter)  Committed
>   svcs -x return code         Committed
>
>   This case requests Patch binding for these interfaces.
>
> 3. References
>
>   PSARC 2004/673 svcs -x (eXplain)
>
> 4. Manual page differences
>
>
> SYNOPSIS
> -    svcs -x [-v] [FMRI]...
> +     svcs -x [-q] [-v] [FMRI]
>
>  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 degraded services.  With
> +     this flag, an error code of 3 indicates services exist that are in
> +     a maintenance state whereas an error code of 0 indicates
> +     no services in the maintenance state.
>
>  EXIT STATUS
> +
> +     3    Services exist in maintenance state.