From liane.praza@sun.com Wed Feb 27 14:05:30 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1RM5Tar004420 for ; Wed, 27 Feb 2008 14:05:29 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1RM5PtP025865 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 28 Feb 2008 06:05:28 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWX00B054135A00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 27 Feb 2008 14:05:27 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWX00C22413RVC0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 27 Feb 2008 14:05:27 -0800 (PST) Received: from [129.146.228.172] (absurd.SFBay.Sun.COM [129.146.228.172]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1RM5QZJ007235; Wed, 27 Feb 2008 14:05:27 -0800 (PST) Date: Wed, 27 Feb 2008 14:05:26 -0800 From: Liane Praza Subject: 2008/159 svcs -xq To: psarc-ext@sun.com Cc: Mark Martin Message-id: <47C5DEA6.7090205@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.9 (X11/20080128) Status: RO Content-Length: 2195 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. From sacadmin Wed Feb 27 14:08:42 2008 Received: from absurd.sfbay.sun.com (absurd [129.146.228.172]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1RM8g5T004569; Wed, 27 Feb 2008 14:08:42 -0800 (PST) Received: from absurd.sfbay.sun.com (localhost [127.0.0.1]) by absurd.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1RM1BVn017534; Wed, 27 Feb 2008 14:01:12 -0800 (PST) Received: (from lianep@localhost) by absurd.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m1RM1Bc4017530; Wed, 27 Feb 2008 14:01:11 -0800 (PST) Date: Wed, 27 Feb 2008 14:01:11 -0800 (PST) From: Liane Praza Message-Id: <200802272201.m1RM1Bc4017530@absurd.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Cc: storycrafter@gmail.com Subject: svcs -xq [PSARC/2008/159 Self Review] Status: RO Content-Length: 544 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: svcs -xq 1.2. Name of Document Author/Supplier: Author: Mark Martin 1.3 Date of This Document: 27 February, 2008 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: Automatic 6.6. ARC Exposure: open From gdamore@sun.com Wed Feb 27 14:30:45 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1RMUiHw006402 for ; Wed, 27 Feb 2008 14:30:45 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1RMUOKi002591 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 27 Feb 2008 22:30:43 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWX00229574Z600@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 27 Feb 2008 15:30:40 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWX00CBI573X390@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 27 Feb 2008 15:30:39 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1RMUdjh026201 for ; Wed, 27 Feb 2008 14:30:39 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWX008014XPUA00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 27 Feb 2008 14:30:39 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWX00GMK572UK80@fe-sfbay-10.sun.com>; Wed, 27 Feb 2008 14:30:39 -0800 (PST) Date: Wed, 27 Feb 2008 14:28:46 -0800 From: "Garrett D'Amore" Subject: Re: 2008/159 svcs -xq In-reply-to: <47C5DEA6.7090205@sun.com> Sender: Garrett.Damore@sun.com To: Liane Praza Cc: psarc-ext@sun.com, Mark Martin Message-id: <47C5E41E.9010207@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C5DEA6.7090205@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 2651 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. From ceri@submonkey.net Wed Feb 27 14:58:25 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1RMwOcV008623 for ; Wed, 27 Feb 2008 14:58:25 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1RMwMkp005830; Wed, 27 Feb 2008 14:58:24 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWX0050R6HB3W00@brm-avmta-1.central.sun.com>; Wed, 27 Feb 2008 15:58:23 -0700 (MST) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWX00CMM6H8X3A0@brm-avmta-1.central.sun.com>; Wed, 27 Feb 2008 15:58:20 -0700 (MST) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1RMonn8028697; Wed, 27 Feb 2008 22:58:20 +0000 (GMT) Received: from mms48es.sun.com ([160.41.221.231] [160.41.221.231]) by relay43i.sun.com with ESMTP id BT-MMP-356597; Wed, 27 Feb 2008 22:58:20 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mms48es.sun.com with ESMTP id BT-MMP-1080585; Wed, 27 Feb 2008 22:58:19 +0000 (Z) Received: from shrike.submonkey.net ([81.106.128.65] [81.106.128.65]) by relay4i.sun.com with ESMTP id BT-MMP-2747029; Wed, 27 Feb 2008 22:58:19 +0000 (Z) Received: from ceri by shrike.submonkey.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JUVEA-0004Pd-7n; Wed, 27 Feb 2008 22:58:18 +0000 Date: Wed, 27 Feb 2008 22:58:18 +0000 From: Ceri Davies Subject: Re: 2008/159 svcs -xq In-reply-to: <47C5DEA6.7090205@sun.com> Sender: Ceri Davies To: Liane Praza Cc: psarc-ext@sun.com Message-id: <20080227225818.GF56223@submonkey.net> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nYySOmuH/HDX6pKp" Content-disposition: inline X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== X-PGP: finger ceri@FreeBSD.org X-Antispam: No, score=-0.2/5.0, scanned in 0.076sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <47C5DEA6.7090205@sun.com> User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 1508 --nYySOmuH/HDX6pKp Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, Feb 27, 2008 at 02:05:26PM -0800, 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). >=20 > If there are concerns, we'll happily turn this into a fasttrack and > let the discussion run its course. >=20 > liane > + 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. >=20 > EXIT STATUS > + > + 3 Services exist in maintenance state. I'd suggest that it's worth adding an exit status for the degraded state as well. Ceri --=20 That must be wonderful! I don't understand it at all. -- Moliere --nYySOmuH/HDX6pKp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHxesKocfcwTS3JF8RAt1QAKCRnTjXHj37Vi98HjK9RXvXCPS/ygCeNrNE npEyzxWLLpog7Ubr9ApmLe8= =MrY4 -----END PGP SIGNATURE----- --nYySOmuH/HDX6pKp-- From liane.praza@sun.com Wed Feb 27 16:24:56 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1S0Otnv012237 for ; Wed, 27 Feb 2008 16:24:55 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1S0Oj2Z020186 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 28 Feb 2008 00:24:54 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWX0060LAHGO400@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 27 Feb 2008 16:24:52 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWX0063ZAHGLF00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 27 Feb 2008 16:24:52 -0800 (PST) Received: from [129.146.228.172] (absurd.SFBay.Sun.COM [129.146.228.172]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1S0OpdO013308; Wed, 27 Feb 2008 16:24:52 -0800 (PST) Date: Wed, 27 Feb 2008 16:24:51 -0800 From: Liane Praza Subject: Re: 2008/159 svcs -xq In-reply-to: <20080227225818.GF56223@submonkey.net> To: Ceri Davies Cc: psarc-ext@sun.com, Mark Martin Message-id: <47C5FF53.1030202@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C5DEA6.7090205@sun.com> <20080227225818.GF56223@submonkey.net> User-Agent: Thunderbird 2.0.0.9 (X11/20080128) Status: RO Content-Length: 1546 Ceri Davies wrote: > On Wed, Feb 27, 2008 at 02:05:26PM -0800, 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 > >> + 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. > > I'd suggest that it's worth adding an exit status for the degraded > state as well. Good catch. Not to put words into Mark's mouth, but... it's a single exit status for all problems. Thus, having a separate status for degraded services would mean differentiating again another status for when some where degraded and some were in maintenance. Considering we also indicate offline as a 'problem' state, I'd think the best thing would be just to rephrase this part of the manpage as "Services exist which are enabled, but not running.", rather than referring explicitly to maintenance. Mark can obviously speak up if he disagrees. liane From Nicolas.Williams@sun.com Wed Feb 27 16:54:55 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1S0ssGe013286 for ; Wed, 27 Feb 2008 16:54:55 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1S0skNo000412; Thu, 28 Feb 2008 08:54:52 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWX00501BVDLG00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 27 Feb 2008 16:54:49 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWX004FABVD3L10@nwk-avmta-1.sfbay.Sun.COM>; Wed, 27 Feb 2008 16:54:49 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m1S0smNC022226; Wed, 27 Feb 2008 18:54:48 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m1S0smGT022225; Wed, 27 Feb 2008 18:54:48 -0600 (CST) Date: Wed, 27 Feb 2008 18:54:48 -0600 From: Nicolas Williams Subject: Re: 2008/159 svcs -xq In-reply-to: <47C5FF53.1030202@sun.com> To: Liane Praza Cc: Ceri Davies , psarc-ext@sun.com, Mark Martin Mail-followup-to: Liane Praza , Ceri Davies , psarc-ext@sun.com, Mark Martin Message-id: <20080228005447.GM21674@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <47C5DEA6.7090205@sun.com> <20080227225818.GF56223@submonkey.net> <47C5FF53.1030202@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1231 On Wed, Feb 27, 2008 at 04:24:51PM -0800, Liane Praza wrote: > Ceri Davies wrote: > >>+ > >>+ 3 Services exist in maintenance state. > > > >I'd suggest that it's worth adding an exit status for the degraded > >state as well. > > Good catch. Well... That wouldn't be good. Currently idmapd can end up in degraded state IF the SMB server is running in workgroup mode and a client (or local ZFS object) refers to a SID other than a well-known SID or a SID relative to the server's. That's because we've not yet resolved the matter of shared configuration, and so idmapd doesn't know that the SMB server is in workgroup mode (also, just because it is doesn't mean that the system doesn't have an Active Directory account, and idmapd could still provide useful mapping services to nfsmapid -- that isn't likely though, I know). So idmapd goes into degraded state when it can't talk to AD and some mapping would require doing just that. Besides, svc.startd doesn't actually implement degraded state at this time (grumble). 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. Nico -- From liane.praza@sun.com Wed Feb 27 17:08:40 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1S18eJp013647 for ; Wed, 27 Feb 2008 17:08:40 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1S18d8P042817; Wed, 27 Feb 2008 18:08:39 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWX00803CIFNC00@nwk-avmta-2.sfbay.sun.com>; Wed, 27 Feb 2008 17:08:39 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWX006O5CIFLI20@nwk-avmta-2.sfbay.sun.com>; Wed, 27 Feb 2008 17:08:39 -0800 (PST) Received: from [10.7.251.216] (punchin-lianep.SFBay.Sun.COM [10.7.251.216]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1S18cmj021061; Wed, 27 Feb 2008 17:08:38 -0800 (PST) Date: Wed, 27 Feb 2008 17:06:45 -0800 From: Liane Praza Subject: Re: 2008/159 svcs -xq In-reply-to: <20080228005447.GM21674@Sun.COM> To: Liane Praza , Ceri Davies , psarc-ext@sun.com, Mark Martin Message-id: <47C60925.7010501@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C5DEA6.7090205@sun.com> <20080227225818.GF56223@submonkey.net> <47C5FF53.1030202@sun.com> <20080228005447.GM21674@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 351 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. liane From Joep.Vesseur@sun.com Thu Feb 28 00:32:45 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1S8WjRb025512 for ; Thu, 28 Feb 2008 00:32:45 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1S8WiQX016405 for <@sunmail2sca.sfbay.sun.com:psarc-ext@Sun.COM>; Thu, 28 Feb 2008 00:32:45 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWX0071BX2JTO00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Thu, 28 Feb 2008 00:32:43 -0800 (PST) Received: from dm-holland-01.uk.sun.com ([129.156.101.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWX003QCX2HC220@nwk-avmta-2.sfbay.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Thu, 28 Feb 2008 00:32:41 -0800 (PST) Received: from sunnl.Holland.Sun.COM (sunnl.Holland.Sun.COM [129.159.237.90]) by dm-holland-01.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id m1S8WdoW013262 for ; Thu, 28 Feb 2008 08:32:40 +0000 (GMT) Received: from [10.16.117.32] (enigma.Holland.Sun.COM [10.16.117.32]) by sunnl.Holland.Sun.COM (8.13.8+Sun/8.13.8) with ESMTP id m1S8Wcib011691; Thu, 28 Feb 2008 09:32:38 +0100 (MET) Date: Thu, 28 Feb 2008 09:32:38 +0100 From: Joep Vesseur Subject: Re: 2008/159 svcs -xq In-reply-to: <47C5DEA6.7090205@sun.com> To: psarc-ext@sun.com Cc: Mark Martin Message-id: <47C671A6.9070309@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 X-Enigmail-Version: 0.95.1 References: <47C5DEA6.7090205@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080129) Status: RO Content-Length: 644 On 02/27/08 23:05, Liane Praza wrote: > + 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. This text reads as if the exit code "3" is only ever set when the user specifies '-xq'. I would assume that the exit code is always set to reflect the command's status and that -q only quiets the output. Joep From ceri@submonkey.net Thu Feb 28 01:25:56 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1S9Pupb026203 for ; Thu, 28 Feb 2008 01:25:56 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1S9Punf028522; Thu, 28 Feb 2008 01:25:56 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWX00A01ZJ84A00@nwk-avmta-2.sfbay.sun.com>; Thu, 28 Feb 2008 01:25:56 -0800 (PST) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWX003ABZJ7BX50@nwk-avmta-2.sfbay.sun.com>; Thu, 28 Feb 2008 01:25:55 -0800 (PST) Received: from relay12i.sun.com (ip122.net129179-4.block1.us.syntegra.com [129.179.4.122]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1S9PsjB011985; Thu, 28 Feb 2008 09:25:55 +0000 (GMT) Received: from mmp14es.sun.com ([160.41.209.24] [160.41.209.24]) by relay12i.sun.com with ESMTP id BT-MMP-585917; Thu, 28 Feb 2008 09:25:54 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp14es.sun.com with ESMTP id BT-MMP-11046; Thu, 28 Feb 2008 09:25:54 +0000 (Z) Received: from shrike.submonkey.net ([81.106.128.65] [81.106.128.65]) by relay1ib.sun.com with ESMTP id BT-MMP-5447446; Thu, 28 Feb 2008 09:25:53 +0000 (Z) Received: from ceri by shrike.submonkey.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JUf1T-000NEy-CT; Thu, 28 Feb 2008 09:25:51 +0000 Date: Thu, 28 Feb 2008 09:25:51 +0000 From: Ceri Davies Subject: Re: 2008/159 svcs -xq In-reply-to: <47C5FF53.1030202@sun.com> Sender: Ceri Davies To: Liane Praza Cc: psarc-ext@sun.com, Mark Martin Message-id: <20080228092551.GA5529@submonkey.net> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ikeVEW9yuYc//A+q" Content-disposition: inline X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== X-PGP: finger ceri@FreeBSD.org X-Antispam: No, score=-2.6/5.0, scanned in 0.311sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <47C5DEA6.7090205@sun.com> <20080227225818.GF56223@submonkey.net> <47C5FF53.1030202@sun.com> User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 2313 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, Feb 27, 2008 at 04:24:51PM -0800, Liane Praza wrote: > Ceri Davies wrote: >> On Wed, Feb 27, 2008 at 02:05:26PM -0800, 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). >>>=20 >>> If there are concerns, we'll happily turn this into a fasttrack and >>> let the discussion run its course. >>>=20 >>> liane >>=20 >>> + 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. >>>=20 >>> EXIT STATUS >>> + >>> + 3 Services exist in maintenance state. >>=20 >> I'd suggest that it's worth adding an exit status for the degraded >> state as well. >=20 > Good catch. >=20 > Not to put words into Mark's mouth, but... it's a single exit status for= =20 > all problems. Thus, having a separate status for degraded services would= =20 > mean differentiating again another status for when some where degraded an= d=20 > some were in maintenance. Considering we also indicate offline as a=20 > 'problem' state, I'd think the best thing would be just to rephrase this= =20 > part of the manpage as "Services exist which are enabled, but not=20 > running.", rather than referring explicitly to maintenance. That would be fine; the important thing is that svcs -xq returning zero definitively means "everything is well". Ceri --=20 That must be wonderful! I don't understand it at all. -- Moliere --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHxn4focfcwTS3JF8RAtS9AJ9yCuqIfB5/J/V7oM1HKyKxwGzrSwCfdwJ5 9EcaW0rDm+07aMoT3JpndRQ= =BpCi -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q-- From storycrafter@gmail.com Thu Feb 28 08:02:16 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1SG2G1P006243 for ; Thu, 28 Feb 2008 08:02:16 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1SG2FhA009118 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 28 Feb 2008 08:02:16 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWY00H4HHVRUU00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 28 Feb 2008 09:02:15 -0700 (MST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWY00AN5HURW4D0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 28 Feb 2008 09:01:40 -0700 (MST) Received: from relay41i.sun.com ([192.5.209.70]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1SFr6au022403 for ; Thu, 28 Feb 2008 16:01:39 +0000 (GMT) Received: from mms48es.sun.com ([160.41.221.231] [160.41.221.231]) by relay41i.sun.com with ESMTP id BT-MMP-237091 for psarc-ext@sun.com; Thu, 28 Feb 2008 16:01:39 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mms48es.sun.com with ESMTP id BT-MMP-839610 for psarc-ext@sun.com; Thu, 28 Feb 2008 16:01:20 +0000 (Z) Received: from rv-out-0910.google.com ([209.85.198.185] [209.85.198.185]) by relay4i.sun.com with ESMTP id BT-MMP-10330749 for psarc-ext@sun.com; Thu, 28 Feb 2008 16:01:20 +0000 (Z) Received: by rv-out-0910.google.com with SMTP id c27so2223901rvf.8 for ; Thu, 28 Feb 2008 08:01:19 -0800 (PST) Received: by 10.141.20.7 with SMTP id x7mr5585399rvi.82.1204214479893; Thu, 28 Feb 2008 08:01:19 -0800 (PST) Received: by 10.140.161.8 with HTTP; Thu, 28 Feb 2008 08:01:19 -0800 (PST) Date: Thu, 28 Feb 2008 10:01:19 -0600 From: Mark Martin Subject: Re: 2008/159 svcs -xq In-reply-to: <47C671A6.9070309@Sun.COM> To: Joep Vesseur Cc: psarc-ext@sun.com Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_E7u2fGRcaBwPB0NQV5KySw)" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=XkyPgyqi4wddsbbwyKRR98hfBmiYuebslIINo0KJnEQ=; b=LnQujqOxDM/DTauDFflf/nuM7HsCUUpQBj85izegEo+MMeZzC/81aD1jyRPzcUPCRw+u3pJdCy+rgNGPx4ESleJQJrSOhfy7XLQBxWWa0hDVhEq8+X5cK9qxgehYFu0mh7x+3sqafxXin0Icr6ADhyu9Qa0hJPAH9gRPcmcykpo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ciDhvrXj3cZKOuPbAr3ywwFKIol9N+XvMjzoN1MY/Iagrn1c+J9QjDj1v8TVlIhA63C2u79h6kzp/RYcUEKP+k17znVDnhkRB+j+rqO/R0m9HreVd75E/psWqGvxcHWWPp3gL2NpB4U8U8dZMpzf6fnhq/rcOj0NbwG+ATckxA0= X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.386sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <47C5DEA6.7090205@sun.com> <47C671A6.9070309@Sun.COM> Status: RO Content-Length: 2305 --Boundary_(ID_E7u2fGRcaBwPB0NQV5KySw) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline On Thu, Feb 28, 2008 at 2:32 AM, Joep Vesseur wrote: > On 02/27/08 23:05, Liane Praza wrote: > > > + 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. > > This text reads as if the exit code "3" is only ever set when the user > specifies '-xq'. I would assume that the exit code is always set to > reflect the command's status and that -q only quiets the output. > This seems reasonable to me. --Boundary_(ID_E7u2fGRcaBwPB0NQV5KySw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline On Thu, Feb 28, 2008 at 2:32 AM, Joep Vesseur <Joep.Vesseur@sun.com> wrote:
On 02/27/08 23:05, Liane Praza wrote:

> +     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.

This text reads as if the exit code "3" is only ever set when the user
specifies '-xq'. I would assume that the exit code is always set to
reflect the command's status and that -q only quiets the output.

This seems reasonable to me.


--Boundary_(ID_E7u2fGRcaBwPB0NQV5KySw)-- From Nicolas.Williams@sun.com Thu Feb 28 08:06:33 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1SG6XZP006387 for ; Thu, 28 Feb 2008 08:06:33 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1SG6IE0010734; Thu, 28 Feb 2008 08:06:33 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWY00I05I2U7800@brm-avmta-1.central.sun.com>; Thu, 28 Feb 2008 09:06:30 -0700 (MST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWY00A84I2TW0E0@brm-avmta-1.central.sun.com>; Thu, 28 Feb 2008 09:06:29 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m1SG6TFF022672; Thu, 28 Feb 2008 10:06:29 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m1SG6OjX022671; Thu, 28 Feb 2008 10:06:24 -0600 (CST) Date: Thu, 28 Feb 2008 10:06:24 -0600 From: Nicolas Williams Subject: Re: 2008/159 svcs -xq In-reply-to: <47C60925.7010501@sun.com> To: Liane Praza Cc: Ceri Davies , psarc-ext@sun.com, Mark Martin Mail-followup-to: Liane Praza , Ceri Davies , psarc-ext@sun.com, Mark Martin Message-id: <20080228160624.GA21674@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <47C5DEA6.7090205@sun.com> <20080227225818.GF56223@submonkey.net> <47C5FF53.1030202@sun.com> <20080228005447.GM21674@Sun.COM> <47C60925.7010501@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 519 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"). From liane.praza@sun.com Thu Feb 28 09:19:46 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1SHJjKJ008787 for ; Thu, 28 Feb 2008 09:19:45 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1SHJiqB028287; Thu, 28 Feb 2008 10:19:44 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWY00H01LGTPX00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 28 Feb 2008 09:19:41 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWY00EPLLGTOG20@nwk-avmta-1.sfbay.Sun.COM>; Thu, 28 Feb 2008 09:19:41 -0800 (PST) Received: from [129.146.228.172] (absurd.SFBay.Sun.COM [129.146.228.172]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1SHJe1m021806; Thu, 28 Feb 2008 09:19:40 -0800 (PST) Date: Thu, 28 Feb 2008 09:19:37 -0800 From: Liane Praza Subject: Re: 2008/159 svcs -xq In-reply-to: <20080228160624.GA21674@Sun.COM> To: Liane Praza , Ceri Davies , psarc-ext@sun.com, Mark Martin Message-id: <47C6ED29.8010806@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C5DEA6.7090205@sun.com> <20080227225818.GF56223@submonkey.net> <47C5FF53.1030202@sun.com> <20080228005447.GM21674@Sun.COM> <47C60925.7010501@sun.com> <20080228160624.GA21674@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (X11/20080128) Status: RO Content-Length: 1655 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 " 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. 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.) liane From storycrafter@gmail.com Tue Mar 4 11:58:45 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m24Jwjju025338 for ; Tue, 4 Mar 2008 11:58:45 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m24Jwisi025999 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 4 Mar 2008 12:58:44 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JX800K0B25VEH00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 04 Mar 2008 12:58:43 -0700 (MST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JX800K5425V9R00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 04 Mar 2008 12:58:43 -0700 (MST) Received: from relay42i.sun.com ([192.5.209.72]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m24JpAwT007357 for ; Tue, 04 Mar 2008 19:58:42 +0000 (GMT) Received: from mms48es.sun.com ([160.41.221.231] [160.41.221.231]) by relay42i.sun.com with ESMTP id BT-MMP-1180105 for psarc-ext@sun.com; Tue, 04 Mar 2008 19:58:42 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mms48es.sun.com with ESMTP id BT-MMP-2548289 for psarc-ext@sun.com; Tue, 04 Mar 2008 19:58:42 +0000 (Z) Received: from wr-out-0506.google.com ([64.233.184.239] [64.233.184.239]) by relay4i.sun.com with ESMTP id BT-MMP-28952461 for psarc-ext@sun.com; Tue, 04 Mar 2008 19:58:42 +0000 (Z) Received: by wr-out-0506.google.com with SMTP id 58so2071638wri.8 for ; Tue, 04 Mar 2008 11:58:42 -0800 (PST) Received: by 10.141.22.1 with SMTP id z1mr906182rvi.282.1204660720095; Tue, 04 Mar 2008 11:58:40 -0800 (PST) Received: by 10.140.161.8 with HTTP; Tue, 04 Mar 2008 11:58:40 -0800 (PST) Date: Tue, 04 Mar 2008 13:58:40 -0600 From: Mark Martin Subject: Re: 2008/159 svcs -xq In-reply-to: <47C6ED29.8010806@sun.com> To: Liane Praza Cc: Ceri Davies , psarc-ext@sun.com Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_gT6KYTrsPCbLlnGczVVMOA)" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=gq9RYzvE4J61KA0EcNluqSSnsk7890TdGne2VvxPVJI=; b=N/q8iLtYet4MpQ4xPt2S9coUZbV4czO7D/sc896cBRpC8xOPFooitS673eHqbLF+TxlhU2BaeFcDkcEAp6fy6YNbpeA3YM3ojBX8tziu0r6sj+5pzpFyt+IJ/XqPddIGajQ5+oMxAphjDFIqDk0N43ZZxcNtR5FiRq0i5Zb86yA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=nrImA50ZNklZlGig4dhgm4TN9wDDp2/df0B/pGVBiHyu/KDEu75nwxG7A9IFNPZC/BaFYiP1lG/QdHMxGFxzCDrqVKPTuHdskOvP5fKqN3QZ8JHHycxhrK8YXQ/chwR3w7Pn+SEtNk1m6u9+GF7gA22INos1Y1KnMQ0+jNBNSIw= X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.122sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <47C5DEA6.7090205@sun.com> <20080227225818.GF56223@submonkey.net> <47C5FF53.1030202@sun.com> <20080228005447.GM21674@Sun.COM> <47C60925.7010501@sun.com> <20080228160624.GA21674@Sun.COM> <47C6ED29.8010806@sun.com> Status: RO Content-Length: 7261 --Boundary_(ID_gT6KYTrsPCbLlnGczVVMOA) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline On Thu, Feb 28, 2008 at 11:19 AM, Liane Praza 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 " 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 --Boundary_(ID_gT6KYTrsPCbLlnGczVVMOA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline On Thu, Feb 28, 2008 at 11:19 AM, Liane Praza <liane.praza@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

--Boundary_(ID_gT6KYTrsPCbLlnGczVVMOA)-- From gdamore@sun.com Wed Mar 5 10:44:25 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m25IiOwF011255 for ; Wed, 5 Mar 2008 10:44:25 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m25IiLOG021514 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 5 Mar 2008 18:44:23 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JX90060VTDXZM00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 Mar 2008 10:44:21 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JX900576TDW2940@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 Mar 2008 10:44:21 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m25IiKRF015870 for ; Wed, 05 Mar 2008 10:44:20 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JX900401T73LQ00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 Mar 2008 10:44:20 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JX900ABBTDS2N90@fe-sfbay-10.sun.com>; Wed, 05 Mar 2008 10:44:17 -0800 (PST) Date: Wed, 05 Mar 2008 10:42:05 -0800 From: "Garrett D'Amore" Subject: Re: 2008/159 svcs -xq In-reply-to: <47C5DEA6.7090205@sun.com> Sender: Garrett.Damore@sun.com To: Liane Praza Cc: psarc-ext@sun.com, Mark Martin Message-id: <47CEE97D.9070704@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C5DEA6.7090205@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 2446 FYI, per the request of Mark Martin at today's PSARC meeting, the timer on this case as been extended to March 13, 2008. -- 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. From liane.praza@sun.com Tue Mar 11 08:04:26 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2BF4Prx022978 for ; Tue, 11 Mar 2008 08:04:25 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2BF4F5h026875 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 11 Mar 2008 23:04:23 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXK00775N78GV00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 11 Mar 2008 08:04:20 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXK003BZN6RYJD0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 11 Mar 2008 08:04:03 -0700 (PDT) Received: from [10.7.251.216] (punchin-lianep.SFBay.Sun.COM [10.7.251.216]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2BF3wK1619423; Tue, 11 Mar 2008 08:03:58 -0700 (PDT) Date: Tue, 11 Mar 2008 08:03:58 -0700 From: Liane Praza Subject: Re: 2008/159 svcs -xq In-reply-to: To: Mark Martin Cc: Ceri Davies , PSARC-ext@sun.com Message-id: <47D69F5E.2070903@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47C5DEA6.7090205@sun.com> <20080227225818.GF56223@submonkey.net> <47C5FF53.1030202@sun.com> <20080228005447.GM21674@Sun.COM> <47C60925.7010501@sun.com> <20080228160624.GA21674@Sun.COM> <47C6ED29.8010806@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 4781 Mark Martin wrote: > On Thu, Feb 28, 2008 at 11:19 AM, Liane Praza > 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 " 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 From ceri@submonkey.net Tue Mar 11 09:06:44 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2BG6h8i025752 for ; Tue, 11 Mar 2008 09:06:44 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2BG69fA002815; Tue, 11 Mar 2008 16:06:41 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXK00525Q33KI00@brm-avmta-1.central.sun.com>; Tue, 11 Mar 2008 10:06:39 -0600 (MDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXK00J3AQ2UMFF0@brm-avmta-1.central.sun.com>; Tue, 11 Mar 2008 10:06:30 -0600 (MDT) Received: from relay43i.sun.com ([192.5.209.74]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2BFaPNd021644; Tue, 11 Mar 2008 16:06:30 +0000 (GMT) Received: from mms49es.sun.com ([160.41.221.233] [160.41.221.233]) by relay43i.sun.com with ESMTP id BT-MMP-209448; Tue, 11 Mar 2008 16:06:29 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mms49es.sun.com with ESMTP id BT-MMP-814967; Tue, 11 Mar 2008 16:06:09 +0000 (Z) Received: from shrike.submonkey.net ([81.106.128.65] [81.106.128.65]) by relay4i.sun.com with ESMTP id BT-MMP-4695374; Tue, 11 Mar 2008 16:06:09 +0000 (Z) Received: from ceri by shrike.submonkey.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JZ6zQ-000GQd-8W; Tue, 11 Mar 2008 16:06:08 +0000 Date: Tue, 11 Mar 2008 16:06:08 +0000 From: Ceri Davies Subject: Re: 2008/159 svcs -xq In-reply-to: <47D69F5E.2070903@sun.com> Sender: Ceri Davies To: Liane Praza Cc: Mark Martin , psarc-ext@sun.com Message-id: <20080311160608.GE62669@submonkey.net> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=H1spWtNR+x+ondvy Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-PGP: finger ceri@FreeBSD.org X-Antispam: No, score=-2.6/5.0, scanned in 0.154sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <47C5DEA6.7090205@sun.com> <20080227225818.GF56223@submonkey.net> <47C5FF53.1030202@sun.com> <20080228005447.GM21674@Sun.COM> <47C60925.7010501@sun.com> <20080228160624.GA21674@Sun.COM> <47C6ED29.8010806@sun.com> <47D69F5E.2070903@sun.com> User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 4420 --H1spWtNR+x+ondvy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 > > wrote: >>=20 >> 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"). >>=20 >> svc.startd isn't using the degraded state. This is a bug. inetd do= es >> use the degraded state. >>=20 >> But, that's orthogonal to the svcs -x behaviour, which I was wrong >> about. >>=20 >> "svcs -x " does attempt to diagnose why a service is in degrad= ed, >> which I misread last night to say that it will display degraded serv= ices >> in its unadorned "svcs -x" invocation. That's not true. My apologi= es. >>=20 >> This means Ceri's request is a new one. It falls out of the scope of >> the current definition of svcs -x: >>=20 >> Without arguments, the -x option >> explains the states of services which: >>=20 >> o are enabled, but are not run- >> ning. >>=20 >> o are preventing another enabled >> service from running. >>=20 >>=20 >> Ok, so just so I have a correct understanding, what is really desired he= re=20 >> is the ability for svcs -x to now also delineate "degraded' services as= =20 >> well as the 2 cases which it is already enumerating. >=20 > I believe so, but I'm not the one that made the request. >=20 >> This might also mean adding degraded state support to svc.startd (or it= =20 >> may not). >=20 > It does not require that. Degraded is defined, and already used by anoth= er=20 > restarter. Making svc.startd (or any other restarter) implement that sta= te=20 > is not required for svcs to change its handling of that state. >=20 >> If this additional state is enumerated, then there should be an=20 >> additional exit code for it (and presumably yet a third for services=20 >> existing in both state buckets). >=20 > Ugh. That's what I'm not at all convinced of. You'd be both changing th= e=20 > default behaviour of svcs -x to print more services (IIRC Nico was oppose= d=20 > to this), and ending up with some kind of weird exit codes. >=20 > I believe Ceri suggested a new option to include degraded services, which= =20 > I'm not necessarily opposed to (though seems a little weird), and if=20 > pursued would require vetting with the SMF community. I guess that would= =20 > solve the exit code stuff, but I really don't believe that the PSARC=20 > aliases are the place to iterate through design proposals, so won't go=20 > 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 --=20 That must be wonderful! I don't understand it at all. -- Moliere --H1spWtNR+x+ondvy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFH1q3vocfcwTS3JF8RAkF7AJ9CkYpnoBz4t2ooDUt69pu+6z2LOACfTJ5+ xP79SdNGzIePaOnzHk6HlkA= =f9Ak -----END PGP SIGNATURE----- --H1spWtNR+x+ondvy-- From storycrafter@gmail.com Tue Mar 11 11:28:13 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2BISDBn003724 for ; Tue, 11 Mar 2008 11:28:13 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2BIS7CR011559 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 11 Mar 2008 18:28:11 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXK0062NWMYX900@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 11 Mar 2008 11:28:10 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXK002P3WMW6C40@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 11 Mar 2008 11:28:08 -0700 (PDT) Received: from relay16i.sun.com (ip126.net129179-4.block1.us.syntegra.com [129.179.4.126]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2BIJbvR023066 for ; Tue, 11 Mar 2008 18:28:07 +0000 (GMT) Received: from mmp13es.sun.com ([160.41.209.23] [160.41.209.23]) by relay16i.sun.com with ESMTP id BT-MMP-182323 for psarc-ext@sun.com; Tue, 11 Mar 2008 18:28:07 +0000 (Z) Received: from relay16i.sun.com (relay16i.sun.com [129.179.4.126]) by mmp13es.sun.com with ESMTP id BT-MMP-207222 for psarc-ext@sun.com; Tue, 11 Mar 2008 18:28:07 +0000 (Z) Received: from wr-out-0506.google.com ([64.233.184.233] [64.233.184.233]) by relay1ib.sun.com with ESMTP id BT-MMP-1281303 for psarc-ext@sun.com; Tue, 11 Mar 2008 18:28:07 +0000 (Z) Received: by wr-out-0506.google.com with SMTP id 58so1837629wri.8 for ; Tue, 11 Mar 2008 11:28:05 -0700 (PDT) Received: by 10.140.144.4 with SMTP id r4mr4614576rvd.15.1205260083828; Tue, 11 Mar 2008 11:28:03 -0700 (PDT) Received: by 10.140.161.8 with HTTP; Tue, 11 Mar 2008 11:28:03 -0700 (PDT) Date: Tue, 11 Mar 2008 13:28:03 -0500 From: Mark Martin Subject: Re: 2008/159 svcs -xq In-reply-to: <20080311160608.GE62669@submonkey.net> To: Ceri Davies Cc: Liane Praza , psarc-ext@sun.com Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_UNNKjTzTbSbHg/rFQklfsw)" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=9ucUeCgG/WTuZYfSbAzXWk4nZOAUxxjEOCMjjA5v6II=; b=UIeqcN4+/12EIw51auMbWcOQ32iL/jC8QqLhpnoe9UwC2OMmPIdedJLGwJZerxeJFdBtOe49SXz5pxZmGK6QOkWYHTO3KWRviMZSIYbvMxz26aVClWi8MjEyOi29VCBiPYjAONTIH0CszbVf9nDuDlE0eXeZdGz0gHB1/7v8KhA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=jGrVqPB0ggiV9gap4Z+ss+Mcw/atkaMzXUHZfXaV7mzBi7wva2+ovlXDsk4Qi+HSx7oBxFJ59cV4kpbYTGC290KbYHYItL5usEg5gS6/zXu819wSlNWrhaO6PHTG2IzvbRNMv4/bbxm2kMBFJQJQFHiCOYIF04mNz5j/VtUwfIA= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.104sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <47C5DEA6.7090205@sun.com> <20080227225818.GF56223@submonkey.net> <47C5FF53.1030202@sun.com> <20080228005447.GM21674@Sun.COM> <47C60925.7010501@sun.com> <20080228160624.GA21674@Sun.COM> <47C6ED29.8010806@sun.com> <47D69F5E.2070903@sun.com> <20080311160608.GE62669@submonkey.net> Status: RO Content-Length: 5872 --Boundary_(ID_UNNKjTzTbSbHg/rFQklfsw) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline On Tue, Mar 11, 2008 at 11:06 AM, Ceri Davies 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 --Boundary_(ID_UNNKjTzTbSbHg/rFQklfsw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline On Tue, Mar 11, 2008 at 11:06 AM, Ceri Davies <ceri@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
--Boundary_(ID_UNNKjTzTbSbHg/rFQklfsw)-- From Nicolas.Williams@sun.com Tue Mar 11 11:55:53 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2BItqaR004641 for ; Tue, 11 Mar 2008 11:55:52 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2BItnll024877; Tue, 11 Mar 2008 18:55:50 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXK00G1KXX0LL00@brm-avmta-1.central.sun.com>; Tue, 11 Mar 2008 12:55:48 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXK0058VXWWVKD0@brm-avmta-1.central.sun.com>; Tue, 11 Mar 2008 12:55:44 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2BItifs010027; Tue, 11 Mar 2008 13:55:44 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m2BIthbK010026; Tue, 11 Mar 2008 13:55:43 -0500 (CDT) Date: Tue, 11 Mar 2008 13:55:43 -0500 From: Nicolas Williams Subject: Re: 2008/159 svcs -xq In-reply-to: <47D69F5E.2070903@sun.com> To: Liane Praza Cc: Mark Martin , Ceri Davies , PSARC-ext@sun.com Mail-followup-to: Liane Praza , Mark Martin , Ceri Davies , PSARC-ext@sun.com Message-id: <20080311185543.GN986@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <47C5DEA6.7090205@sun.com> <20080227225818.GF56223@submonkey.net> <47C5FF53.1030202@sun.com> <20080228005447.GM21674@Sun.COM> <47C60925.7010501@sun.com> <20080228160624.GA21674@Sun.COM> <47C6ED29.8010806@sun.com> <47D69F5E.2070903@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 798 On Tue, Mar 11, 2008 at 08:03:58AM -0700, Liane Praza wrote: > 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. My objection was, admittedly, weak. IIRC I conceded that when I made it. I think the simplest thing to do would be to have one error code mean "one or more services in maintenance state" another to mean "no services in maintenance but one or more degraded" and, of course, 0 ("no services in maintenance and no services degraded"). Actually, even simpler: tell me to stuff it :) (In which case we'll simply up the priority on common config storage for props that the SMB server and idmap want to share.) Nico -- From storycrafter@gmail.com Tue Mar 11 12:01:42 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2BJ1gMf004830 for ; Tue, 11 Mar 2008 12:01:42 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2BJ1WxH049581 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 Mar 2008 13:01:42 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXK0096ZY6TWH00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 Mar 2008 12:01:41 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXK0029TY6R6080@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 Mar 2008 12:01:39 -0700 (PDT) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2BIvnxY009249 for ; Tue, 11 Mar 2008 19:01:38 +0000 (GMT) Received: from mms48es.sun.com ([160.41.221.231] [160.41.221.231]) by relay43i.sun.com with ESMTP id BT-MMP-239410 for PSARC-ext@sun.com; Tue, 11 Mar 2008 19:01:38 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mms48es.sun.com with ESMTP id BT-MMP-2202634 for PSARC-ext@sun.com; Tue, 11 Mar 2008 19:01:15 +0000 (Z) Received: from wr-out-0506.google.com ([64.233.184.227] [64.233.184.227]) by relay4i.sun.com with ESMTP id BT-MMP-5514996 for PSARC-ext@sun.com; Tue, 11 Mar 2008 19:01:15 +0000 (Z) Received: by wr-out-0506.google.com with SMTP id 58so1858499wri.8 for ; Tue, 11 Mar 2008 12:01:15 -0700 (PDT) Received: by 10.141.15.19 with SMTP id s19mr4587575rvi.269.1205262074368; Tue, 11 Mar 2008 12:01:14 -0700 (PDT) Received: by 10.140.161.8 with HTTP; Tue, 11 Mar 2008 12:01:14 -0700 (PDT) Date: Tue, 11 Mar 2008 13:01:14 -0600 From: Mark Martin Subject: Re: 2008/159 svcs -xq In-reply-to: <20080311185543.GN986@Sun.COM> To: Liane Praza , Mark Martin , Ceri Davies , PSARC-ext@sun.com Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_VnbdPjPLUYsVoyZ2aPqm0Q)" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=+NgpOtXYJ+SrwopNut80xnmC8G9y1oC7XlgSMNSCfCs=; b=Zvschr+afM0ze8qrGpD0lbY1AGRohjd8g83oLgyshangvHyaB3kSfeXHtV2royfEhfWvbDAJxNxc7weRRLgstBcqiHcOLkruxjgLVRNEhOJRRk7ckJVYHfsu63PhBvEranXrJD4nt+fMsBLYHP6FzF0sZKt9kPda8FPREawJGIU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=gao+rc8xFkmGdh/ucA4Rs+xdqNDwNm8WzHrNHqb5LCvDY8yHpkN3W2YHQYbxlhs7yLmfhWBaAdp93VSAUIt2AiDn9wxUTshR783efcBNQWPpRv4HNntqkxcCJuVGIl0gN5xnduYt9RWKoFUQ31X4M9Qv1OeZ1ZoFUleKtTwI7A4= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.351sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <47C5DEA6.7090205@sun.com> <20080227225818.GF56223@submonkey.net> <47C5FF53.1030202@sun.com> <20080228005447.GM21674@Sun.COM> <47C60925.7010501@sun.com> <20080228160624.GA21674@Sun.COM> <47C6ED29.8010806@sun.com> <47D69F5E.2070903@sun.com> <20080311185543.GN986@Sun.COM> Status: RO Content-Length: 3264 --Boundary_(ID_VnbdPjPLUYsVoyZ2aPqm0Q) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline On Tue, Mar 11, 2008 at 12:55 PM, Nicolas Williams wrote: > On Tue, Mar 11, 2008 at 08:03:58AM -0700, Liane Praza wrote: > > 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. > > My objection was, admittedly, weak. IIRC I conceded that when I made > it. > > I think the simplest thing to do would be to have one error code mean > "one or more services in maintenance state" another to mean "no services > in maintenance but one or more degraded" and, of course, 0 ("no services > in maintenance and no services degraded"). > > Actually, even simpler: tell me to stuff it :) (In which case we'll > simply up the priority on common config storage for props that the SMB > server and idmap want to share.) > I'd rather keep the simple errorlevel semantic: 0 = svcs -x prints nothing, 3 = svcs -x prints something. Getting svcs -x to squawk more about degraded services should be another case. Besides, I'd rather see the priority on common config storage upgraded (although I lack the fortitude to tell anyone here to get stuffed). Mark --Boundary_(ID_VnbdPjPLUYsVoyZ2aPqm0Q) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline On Tue, Mar 11, 2008 at 12:55 PM, Nicolas Williams <Nicolas.Williams@sun.com> wrote:
On Tue, Mar 11, 2008 at 08:03:58AM -0700, Liane Praza wrote:
> 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.

My objection was, admittedly, weak.  IIRC I conceded that when I made
it.

I think the simplest thing to do would be to have one error code mean
"one or more services in maintenance state" another to mean "no services
in maintenance but one or more degraded" and, of course, 0 ("no services
in maintenance and no services degraded").

Actually, even simpler: tell me to stuff it :)  (In which case we'll
simply up the priority on common config storage for props that the SMB
server and idmap want to share.)


I'd rather keep the simple errorlevel semantic:  0 = svcs -x prints nothing, 3 = svcs -x prints something.

Getting svcs -x to squawk more about degraded services should be another case.

Besides, I'd rather see the priority on common config storage upgraded (although I lack the fortitude to tell anyone here to get stuffed).
 
Mark


--Boundary_(ID_VnbdPjPLUYsVoyZ2aPqm0Q)-- From ceri@submonkey.net Tue Mar 11 12:09:53 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2BJ9rkg006049 for ; Tue, 11 Mar 2008 12:09:53 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2BJ9qc6012838; Tue, 11 Mar 2008 12:09:53 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXK00A05YKGR500@nwk-avmta-1.sfbay.Sun.COM>; Tue, 11 Mar 2008 12:09:52 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXK002XDYKF6470@nwk-avmta-1.sfbay.Sun.COM>; Tue, 11 Mar 2008 12:09:51 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2BIRcR0026382; Tue, 11 Mar 2008 19:09:51 +0000 (GMT) Received: from mms49es.sun.com ([160.41.221.233] [160.41.221.233]) by relay42i.sun.com with ESMTP id BT-MMP-252778; Tue, 11 Mar 2008 19:09:50 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mms49es.sun.com with ESMTP id BT-MMP-2355575; Tue, 11 Mar 2008 19:08:20 +0000 (Z) Received: from shrike.submonkey.net ([81.106.128.65] [81.106.128.65]) by relay4i.sun.com with ESMTP id BT-MMP-5419672; Tue, 11 Mar 2008 19:08:10 +0000 (Z) Received: from ceri by shrike.submonkey.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JZ9pT-00033s-BP; Tue, 11 Mar 2008 19:08:03 +0000 Date: Tue, 11 Mar 2008 19:08:03 +0000 From: Ceri Davies Subject: Re: 2008/159 svcs -xq In-reply-to: Sender: Ceri Davies To: Mark Martin Cc: Liane Praza , PSARC-ext@sun.com Message-id: <20080311190803.GH62669@submonkey.net> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/Uq4LBwYP4y1W6pO" Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-PGP: finger ceri@FreeBSD.org X-Antispam: No, score=-1.1/5.0, scanned in 0.671sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <20080227225818.GF56223@submonkey.net> <47C5FF53.1030202@sun.com> <20080228005447.GM21674@Sun.COM> <47C60925.7010501@sun.com> <20080228160624.GA21674@Sun.COM> <47C6ED29.8010806@sun.com> <47D69F5E.2070903@sun.com> <20080311160608.GE62669@submonkey.net> User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 1592 --/Uq4LBwYP4y1W6pO Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tue, Mar 11, 2008 at 01:28:03PM -0500, Mark Martin wrote: > EXIT STATUS > + > + 3 Services exist in problematic state. >=20 > Ceri, as to your point about (service_degraded =3D=3D all_is_well), that'= s out > of scope for this case. I'll file a bug for svcs -x showing degraded sta= te > and we can hash that at a later date. That suits me OK, although I'm still not really happy with the implication, particularly in the EXIT STATUS section above, that "problematic" wouldn't include 'degraded'. What the exit status really indicates is that services that should be 'online' are presently either in maintenance, waiting for a dependency to come online (?) or, if you're very quick, possibly uninitialised. I'd prefer that be made explicit since I definitely would parse that statement as including 'degraded'. I'd be equally happy for svcs to grow a -X option for including degraded services which should be reasonably interface safe, rather than extending svcs -x and possibly breaking stuff. Thanks all,=20 Ceri --=20 That must be wonderful! I don't understand it at all. -- Moliere --/Uq4LBwYP4y1W6pO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFH1tiSocfcwTS3JF8RAjm6AKCUmLns3REWN1rCj2urp/84uOxirwCfWisP 6iISwOdZmUipP9v0fjAs3b8= =l2hm -----END PGP SIGNATURE----- --/Uq4LBwYP4y1W6pO-- From Nicolas.Williams@sun.com Tue Mar 11 12:22:18 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2BJMI2b006856 for ; Tue, 11 Mar 2008 12:22:18 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2BJMIXs016115; Tue, 11 Mar 2008 12:22:18 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXK00B01Z56VG00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 11 Mar 2008 12:22:18 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXK002JCZ536980@nwk-avmta-1.sfbay.Sun.COM>; Tue, 11 Mar 2008 12:22:16 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2BJMFIX010179; Tue, 11 Mar 2008 14:22:15 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m2BJMFcW010178; Tue, 11 Mar 2008 14:22:15 -0500 (CDT) Date: Tue, 11 Mar 2008 14:22:15 -0500 From: Nicolas Williams Subject: Re: 2008/159 svcs -xq In-reply-to: To: Mark Martin Cc: Liane Praza , Ceri Davies , PSARC-ext@sun.com Mail-followup-to: Mark Martin , Liane Praza , Ceri Davies , PSARC-ext@sun.com Message-id: <20080311192215.GP986@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <20080227225818.GF56223@submonkey.net> <47C5FF53.1030202@sun.com> <20080228005447.GM21674@Sun.COM> <47C60925.7010501@sun.com> <20080228160624.GA21674@Sun.COM> <47C6ED29.8010806@sun.com> <47D69F5E.2070903@sun.com> <20080311185543.GN986@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 679 On Tue, Mar 11, 2008 at 01:01:14PM -0600, Mark Martin wrote: > On Tue, Mar 11, 2008 at 12:55 PM, Nicolas Williams > wrote: > > My objection was, admittedly, weak. IIRC I conceded that when I made > > it. > > I'd rather keep the simple errorlevel semantic: 0 = svcs -x prints nothing, > 3 = svcs -x prints something. > > Getting svcs -x to squawk more about degraded services should be another > case. > > Besides, I'd rather see the priority on common config storage upgraded > (although I lack the fortitude to tell anyone here to get stuffed). Better learn quick! :) OK, so, Liane: here's your chance -last chance- to tell me to stuff it :) From storycrafter@gmail.com Tue Mar 11 12:56:08 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2BJu72B008029 for ; Tue, 11 Mar 2008 12:56:07 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2BJu6Pi019377 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 11 Mar 2008 19:56:06 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXL00K2Z0PHQU00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 11 Mar 2008 13:56:05 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXL00JY80PCA520@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 11 Mar 2008 13:56:00 -0600 (MDT) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2BJ6Yno016212 for ; Tue, 11 Mar 2008 19:56:00 +0000 (GMT) Received: from mms48es.sun.com ([160.41.221.231] [160.41.221.231]) by relay42i.sun.com with ESMTP id BT-MMP-260663 for psarc-ext@sun.com; Tue, 11 Mar 2008 19:55:59 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mms48es.sun.com with ESMTP id BT-MMP-2713245 for psarc-ext@sun.com; Tue, 11 Mar 2008 19:55:29 +0000 (Z) Received: from wx-out-0506.google.com ([66.249.82.225] [66.249.82.225]) by relay4i.sun.com with ESMTP id BT-MMP-5648688 for psarc-ext@sun.com; Tue, 11 Mar 2008 19:55:29 +0000 (Z) Received: by wx-out-0506.google.com with SMTP id s11so2399566wxc.17 for ; Tue, 11 Mar 2008 12:55:29 -0700 (PDT) Received: by 10.140.172.19 with SMTP id u19mr4717419rve.31.1205265328291; Tue, 11 Mar 2008 12:55:28 -0700 (PDT) Received: by 10.140.161.8 with HTTP; Tue, 11 Mar 2008 12:55:28 -0700 (PDT) Date: Tue, 11 Mar 2008 13:55:28 -0600 From: Mark Martin Subject: Re: 2008/159 svcs -xq In-reply-to: <20080311190803.GH62669@submonkey.net> To: Ceri Davies Cc: Liane Praza , PSARC-ext@sun.com Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_USCPpMHlsJKoj2H3COAamQ)" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=GIYqjOC8TmHrpxHKUy1e0mBFB7kua8pLlnQ7KkoTWMQ=; b=QD/J0r4Qdm6GHUmk0Py9/oR1JoJxSaE6GvgqN4k8qk/LEJbad7cj/MKQ/q3tAVWtW1LAf547RZffvNE9dRBIvTZN2P1bjGeGRhJ8nn1D9OBlESDWr0RQN8dYTplo+EzvwpWdiMEmLEDTxL3lJNrxo4MTbjhQYih3FDFYlN2+QTQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=s2zHBs6T7LMUgnGjAdyRk+IPPhwsE2zNe1tPP+WLWz0xjIZs3EZCEtR+4gDVPVBkjAMZA1JgFUgW5gPA5kchnaQge7wqMst0i4OUgqPO+rZQjUMzLsQGEGqUnNlLxQY+9RRJAjjv99DVkSrajyMWH6tmFY67M9haDWTKC/yjmHA= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.171sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <20080227225818.GF56223@submonkey.net> <20080228005447.GM21674@Sun.COM> <47C60925.7010501@sun.com> <20080228160624.GA21674@Sun.COM> <47C6ED29.8010806@sun.com> <47D69F5E.2070903@sun.com> <20080311160608.GE62669@submonkey.net> <20080311190803.GH62669@submonkey.net> Status: RO Content-Length: 3790 --Boundary_(ID_USCPpMHlsJKoj2H3COAamQ) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline On Tue, Mar 11, 2008 at 1:08 PM, Ceri Davies wrote: > On Tue, Mar 11, 2008 at 01:28:03PM -0500, Mark Martin wrote: > > > 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. > > That suits me OK, although I'm still not really happy with the > implication, particularly in the EXIT STATUS section above, that > "problematic" wouldn't include 'degraded'. What the exit status really > indicates is that services that should be 'online' are presently either > in maintenance, waiting for a dependency to come online (?) or, if > you're very quick, possibly uninitialised. I'd prefer that be made > explicit since I definitely would parse that statement as including > 'degraded'. > EXIT STATUS + + 3 Services exist which are in the maintenance state or + are blocking other enabled services 'zat ok? Mark > I'd be equally happy for svcs to grow a -X option for including degraded > services which should be reasonably interface safe, rather than > extending svcs -x and possibly breaking stuff. > Bug submitted. I'll follow up with a bug id after it makes the rounds to the outside. --Boundary_(ID_USCPpMHlsJKoj2H3COAamQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline On Tue, Mar 11, 2008 at 1:08 PM, Ceri Davies <ceri@submonkey.net> wrote:
On Tue, Mar 11, 2008 at 01:28:03PM -0500, Mark Martin wrote:

>  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.

That suits me OK, although I'm still not really happy with the
implication, particularly in the EXIT STATUS section above, that
"problematic" wouldn't include 'degraded'.  What the exit status really
indicates is that services that should be 'online' are presently either
in maintenance, waiting for a dependency to come online (?)  or, if
you're very quick, possibly uninitialised.  I'd prefer that be made
explicit since I definitely would parse that statement as including
'degraded'.

  EXIT STATUS
  +
  +     3    Services exist which are in the maintenance state or
  +            are blocking other enabled services

'zat ok?

Mark


I'd be equally happy for svcs to grow a -X option for including degraded
services which should be reasonably interface safe, rather than
extending svcs -x and possibly breaking stuff.

Bug submitted.  I'll follow up with a bug id after it makes the rounds to the outside.
--Boundary_(ID_USCPpMHlsJKoj2H3COAamQ)-- From ceri@submonkey.net Tue Mar 11 13:02:56 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2BK2tCS008198 for ; Tue, 11 Mar 2008 13:02:56 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2BK2cRO028135; Wed, 12 Mar 2008 04:02:53 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXL00F0510PTR00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 11 Mar 2008 13:02:49 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXL002SA10P69B0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 11 Mar 2008 13:02:49 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2BJsl5b005488; Tue, 11 Mar 2008 20:02:48 +0000 (GMT) Received: from mmp11es.sun.com ([160.41.209.21] [160.41.209.21]) by relay13i.sun.com with ESMTP id BT-MMP-177056; Tue, 11 Mar 2008 20:02:48 +0000 (Z) Received: from relay17i.sun.com (relay17i.sun.com [129.179.4.127]) by mmp11es.sun.com with ESMTP id BT-MMP-4484679; Tue, 11 Mar 2008 20:02:48 +0000 (Z) Received: from shrike.submonkey.net ([81.106.128.65] [81.106.128.65]) by relay1ib.sun.com with ESMTP id BT-MMP-3525503; Tue, 11 Mar 2008 20:02:47 +0000 (Z) Received: from ceri by shrike.submonkey.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JZAgP-0004eP-G6; Tue, 11 Mar 2008 20:02:45 +0000 Date: Tue, 11 Mar 2008 20:02:45 +0000 From: Ceri Davies Subject: Re: 2008/159 svcs -xq In-reply-to: Sender: Ceri Davies To: Mark Martin Cc: Liane Praza , psarc-ext@sun.com Message-id: <20080311200245.GI62669@submonkey.net> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=fXStkuK2IQBfcDe+ Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-PGP: finger ceri@FreeBSD.org X-Antispam: No, score=-2.6/5.0, scanned in 0.167sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <20080228005447.GM21674@Sun.COM> <47C60925.7010501@sun.com> <20080228160624.GA21674@Sun.COM> <47C6ED29.8010806@sun.com> <47D69F5E.2070903@sun.com> <20080311160608.GE62669@submonkey.net> <20080311190803.GH62669@submonkey.net> User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 2106 --fXStkuK2IQBfcDe+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 11, 2008 at 01:55:28PM -0600, Mark Martin wrote: > On Tue, Mar 11, 2008 at 1:08 PM, Ceri Davies wrote: >=20 > > On Tue, Mar 11, 2008 at 01:28:03PM -0500, Mark Martin wrote: > > > > > EXIT STATUS > > > + > > > + 3 Services exist in problematic state. > > > > > > Ceri, as to your point about (service_degraded =3D=3D all_is_well), t= hat'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. > > > > That suits me OK, although I'm still not really happy with the > > implication, particularly in the EXIT STATUS section above, that > > "problematic" wouldn't include 'degraded'. What the exit status really > > indicates is that services that should be 'online' are presently either > > in maintenance, waiting for a dependency to come online (?) or, if > > you're very quick, possibly uninitialised. I'd prefer that be made > > explicit since I definitely would parse that statement as including > > 'degraded'. > > >=20 > EXIT STATUS > + > + 3 Services exist which are in the maintenance state or > + are blocking other enabled services >=20 > 'zat ok? It is with me, thanks again! > > I'd be equally happy for svcs to grow a -X option for including degraded > > services which should be reasonably interface safe, rather than > > extending svcs -x and possibly breaking stuff. > > >=20 > Bug submitted. I'll follow up with a bug id after it makes the rounds to > the outside. Cool. Ceri --=20 That must be wonderful! I don't understand it at all. -- Moliere --fXStkuK2IQBfcDe+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFH1uVlocfcwTS3JF8RAkcIAKCtbNCYvEKcnaMv5akJC17bYMmauwCfeVxS dSmBcS8K51zv7Mi98jObBRg= =PD5y -----END PGP SIGNATURE----- --fXStkuK2IQBfcDe+-- From storycrafter@gmail.com Tue Mar 11 13:14:46 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2BKEjNR008528 for ; Tue, 11 Mar 2008 13:14:45 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2BKEXJc003171 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 12 Mar 2008 04:14:44 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXL00L2Z1KIYI00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 11 Mar 2008 14:14:42 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXL00J0O1KGA250@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 11 Mar 2008 14:14:40 -0600 (MDT) Received: from relay42i.sun.com ([192.5.209.72]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2BK8G2G022925 for ; Tue, 11 Mar 2008 20:14:40 +0000 (GMT) Received: from mms48es.sun.com ([160.41.221.231] [160.41.221.231]) by relay42i.sun.com with ESMTP id BT-MMP-264155 for psarc-ext@sun.com; Tue, 11 Mar 2008 20:14:40 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mms48es.sun.com with ESMTP id BT-MMP-2870794 for psarc-ext@sun.com; Tue, 11 Mar 2008 20:14:40 +0000 (Z) Received: from wr-out-0506.google.com ([64.233.184.225] [64.233.184.225]) by relay4i.sun.com with ESMTP id BT-MMP-5862434 for psarc-ext@sun.com; Tue, 11 Mar 2008 20:14:40 +0000 (Z) Received: by wr-out-0506.google.com with SMTP id 58so1902671wri.8 for ; Tue, 11 Mar 2008 13:14:39 -0700 (PDT) Received: by 10.140.170.12 with SMTP id s12mr4734787rve.83.1205266479024; Tue, 11 Mar 2008 13:14:39 -0700 (PDT) Received: by 10.140.161.8 with HTTP; Tue, 11 Mar 2008 13:14:38 -0700 (PDT) Date: Tue, 11 Mar 2008 14:14:38 -0600 From: Mark Martin Subject: Re: 2008/159 svcs -xq In-reply-to: <20080311200245.GI62669@submonkey.net> To: psarc-ext@sun.com, opensolaris-arc@opensolaris.org Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_0vHuTw4ozkCyV1j2F22Vpg)" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=ygcW/dZKZpd0LEiAh0jLYEsLx4aEAYHQoQXTFkiEJUg=; b=l2dVBQmjSbS3yRZU6CnuhB07Ny7J7/IxD2anIowgWnhV4ZET687XzMvRbFe4sPs5w5kqjAccYj14+2+Dn5t2eTXHQquadu3MfGZMS1604HtiTD3syDjVey49Xq3KV4cTcQsGK/3arQRpqnq5tt9Me1HjHwzC1mJCkOxUZdUqQzs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=h7n6FdBuvys4SJ4/Z4uu2R3CUBBjwaEuKORtuu02mu9h/X2zCWnEMPyW7P1fPDI60Y6URbzD+bB8PiAHIDv9ISI8NRLv73UlbpD+q46XnUZV7nQmwGjJjO6/YcDZYVgPHlBhhfevEVkJK0RLtJcm4Vk21KR7llHTIxyxwGMlAMA= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.094sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <20080228005447.GM21674@Sun.COM> <20080228160624.GA21674@Sun.COM> <47C6ED29.8010806@sun.com> <47D69F5E.2070903@sun.com> <20080311160608.GE62669@submonkey.net> <20080311190803.GH62669@submonkey.net> <20080311200245.GI62669@submonkey.net> Status: RO Content-Length: 5177 --Boundary_(ID_0vHuTw4ozkCyV1j2F22Vpg) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline [final revision - /hopefully/] 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 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 which are in the maintenance state or + are blocking other enabled services. --Boundary_(ID_0vHuTw4ozkCyV1j2F22Vpg) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline [final revision - /hopefully/]

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 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 which are in the maintenance state or
+            are blocking other enabled services.


--Boundary_(ID_0vHuTw4ozkCyV1j2F22Vpg)-- From storycrafter@gmail.com Tue Mar 11 13:25:08 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2BKP71e009006 for ; Tue, 11 Mar 2008 13:25:08 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2BKOxwJ007340 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 12 Mar 2008 04:25:06 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXL00G1521TC300@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 11 Mar 2008 13:25:05 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXL00B8D21NVX90@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 11 Mar 2008 13:25:03 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2BKCOkH008205 for ; Tue, 11 Mar 2008 20:24:59 +0000 (GMT) Received: from mms49es.sun.com ([160.41.221.233] [160.41.221.233]) by relay41i.sun.com with ESMTP id BT-MMP-262698 for psarc-ext@sun.com; Tue, 11 Mar 2008 20:24:59 +0000 (Z) Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mms49es.sun.com with ESMTP id BT-MMP-3046642 for psarc-ext@sun.com; Tue, 11 Mar 2008 20:24:58 +0000 (Z) Received: from rv-out-0910.google.com ([209.85.198.191] [209.85.198.191]) by relay4i.sun.com with ESMTP id BT-MMP-20288282 for psarc-ext@sun.com; Tue, 11 Mar 2008 20:24:58 +0000 (Z) Received: by rv-out-0910.google.com with SMTP id c27so1474010rvf.8 for ; Tue, 11 Mar 2008 13:24:58 -0700 (PDT) Received: by 10.141.211.13 with SMTP id n13mr4719000rvq.184.1205267098344; Tue, 11 Mar 2008 13:24:58 -0700 (PDT) Received: by 10.140.161.8 with HTTP; Tue, 11 Mar 2008 13:24:58 -0700 (PDT) Date: Tue, 11 Mar 2008 14:24:58 -0600 From: Mark Martin Subject: Re: 2008/159 svcs -xq In-reply-to: <20080311200245.GI62669@submonkey.net> To: Ceri Davies Cc: Liane Praza , PSARC-ext@sun.com Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_lwWN+hd6diJ4Zet2IWILlw)" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=P8maMdxu9BoVuWaJVMHuKl8Yr/CiILcLa2i2Vf+I7Tc=; b=Y+IEJX+qs+U/eQ20tomsKSwMPhqrLrcB5N6CCpqNu6ivvAmsa8d2sOLiW8Ky6JMOjhUx3erEeXlLfsR1vcZ951a4ADFnqQ4LoJ1qNHIvPd/sI+3Dnx0LHNfl/udBKCfFVJV75RtHqqEJx97XL4SyQYOpqDCZOsXSjfx8bBqraL0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=xhfOoK0tiINDCIhhY1MoS+WaHVp3nTA58Pdzwv+wpAlvgYvj01suXXw1FSgmoTBtGZ94vQT+Aps+Tf4BQljicufZoZCBtWef+gBTZWCPOjYqrLwI4Wwr44kxYrURFnULyZpk19+mxgQn6tfuZFgr5IZ8ux5zODFf5iBvCGh61i8= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.051sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <20080228005447.GM21674@Sun.COM> <20080228160624.GA21674@Sun.COM> <47C6ED29.8010806@sun.com> <47D69F5E.2070903@sun.com> <20080311160608.GE62669@submonkey.net> <20080311190803.GH62669@submonkey.net> <20080311200245.GI62669@submonkey.net> Status: RO Content-Length: 1079 --Boundary_(ID_lwWN+hd6diJ4Zet2IWILlw) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline On Tue, Mar 11, 2008 at 2:02 PM, Ceri Davies wrote: [snip] > > On Tue, Mar 11, 2008 at 01:55:28PM -0600, Mark Martin wrote: > > > > Bug submitted. I'll follow up with a bug id after it makes the rounds to > > the outside. > 6674061 svcs -X to show degraded services (like svcs -x does) --Boundary_(ID_lwWN+hd6diJ4Zet2IWILlw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline On Tue, Mar 11, 2008 at 2:02 PM, Ceri Davies <ceri@submonkey.net> wrote:
[snip]
>
> On Tue, Mar 11, 2008 at 01:55:28PM -0600, Mark Martin wrote:
>
>
> > Bug submitted.  I'll follow up with a bug id after it makes the rounds to
> > the outside.
>

6674061 svcs -X to show degraded services (like svcs -x does)
  --Boundary_(ID_lwWN+hd6diJ4Zet2IWILlw)-- From liane.praza@sun.com Tue Mar 11 13:27:36 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2BKRZaS009144 for ; Tue, 11 Mar 2008 13:27:35 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2BKRTgD008141; Wed, 12 Mar 2008 04:27:32 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXL00I0N25V3100@nwk-avmta-1.sfbay.Sun.COM>; Tue, 11 Mar 2008 13:27:31 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXL0029V25T6BE0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 11 Mar 2008 13:27:29 -0700 (PDT) Received: from [129.146.228.161] (nihil.SFBay.Sun.COM [129.146.228.161]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2BKRTh5150277; Tue, 11 Mar 2008 13:27:29 -0700 (PDT) Date: Tue, 11 Mar 2008 13:27:28 -0700 From: Liane Praza Subject: Re: 2008/159 svcs -xq In-reply-to: <20080311192215.GP986@Sun.COM> To: Mark Martin , Liane Praza , Ceri Davies , PSARC-ext@sun.com Message-id: <47D6EB30.2080102@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20080227225818.GF56223@submonkey.net> <47C5FF53.1030202@sun.com> <20080228005447.GM21674@Sun.COM> <47C60925.7010501@sun.com> <20080228160624.GA21674@Sun.COM> <47C6ED29.8010806@sun.com> <47D69F5E.2070903@sun.com> <20080311185543.GN986@Sun.COM> <20080311192215.GP986@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (X11/20080201) Status: RO Content-Length: 874 Nicolas Williams wrote: > On Tue, Mar 11, 2008 at 01:01:14PM -0600, Mark Martin wrote: >> On Tue, Mar 11, 2008 at 12:55 PM, Nicolas Williams >> wrote: >>> My objection was, admittedly, weak. IIRC I conceded that when I made >>> it. >> I'd rather keep the simple errorlevel semantic: 0 = svcs -x prints nothing, >> 3 = svcs -x prints something. >> >> Getting svcs -x to squawk more about degraded services should be another >> case. >> >> Besides, I'd rather see the priority on common config storage upgraded >> (although I lack the fortitude to tell anyone here to get stuffed). > > Better learn quick! :) > > OK, so, Liane: here's your chance -last chance- to tell me to stuff it :) I think Mark's updated proposal is quite sensible. I'd like to reserve my right to tell you to stuff it on other topics in the future, though. ;) liane From storycrafter@gmail.com Wed Mar 12 08:30:23 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2CFUMdd016415 for ; Wed, 12 Mar 2008 08:30:22 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2CFUCuW006712 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 12 Mar 2008 15:30:21 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXM00D0RJ2KJE00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 12 Mar 2008 09:30:20 -0600 (MDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXM008ESJ2AR670@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 12 Mar 2008 09:30:10 -0600 (MDT) Received: from relay43i.sun.com ([192.5.209.74]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2CFLg5S011222 for ; Wed, 12 Mar 2008 15:30:10 +0000 (GMT) Received: from mms48es.sun.com ([160.41.221.231] [160.41.221.231]) by relay43i.sun.com with ESMTP id BT-MMP-421651 for psarc-ext@sun.com; Wed, 12 Mar 2008 15:30:10 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mms48es.sun.com with ESMTP id BT-MMP-4735805 for psarc-ext@sun.com; Wed, 12 Mar 2008 15:30:09 +0000 (Z) Received: from po-out-1718.google.com ([72.14.252.154] [72.14.252.154]) by relay4i.sun.com with ESMTP id BT-MMP-3284602 for psarc-ext@sun.com; Wed, 12 Mar 2008 15:30:09 +0000 (Z) Received: by po-out-1718.google.com with SMTP id y22so4855822pof.3 for ; Wed, 12 Mar 2008 08:30:08 -0700 (PDT) Received: by 10.140.171.4 with SMTP id t4mr5171767rve.230.1205335808451; Wed, 12 Mar 2008 08:30:08 -0700 (PDT) Received: by 10.140.161.8 with HTTP; Wed, 12 Mar 2008 08:30:08 -0700 (PDT) Date: Wed, 12 Mar 2008 09:30:08 -0600 From: Mark Martin Subject: Re: 2008/159 svcs -xq In-reply-to: To: psarc-ext@sun.com, opensolaris-arc@opensolaris.org Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_K1pgkwFmo6S/r8BzUq/hLw)" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=RLpaxpBOdgnOOBSDrsSHMgTS4NFjcp1uF6anL9RzlRw=; b=klZ6PBdzLYLXwqLx+t28VbGH2kSIpaaapOPySlvrxTmbrBjfPmk8QdJvly3m3gU9PsDMlx3jfHS58tP19Lr4BJdfczumVwtfqsyqOJHInjYb1KFEteRrPKsFzBz5hBKSE1++9+w/wNaZz9RNjPLifRswvIQRFQ77clmg+0ynyGU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=KARdTdsLp5ngxyyXirtNx6r98110R79rwdHIgJELHx9OmdTu77uWdd8MPe3Nl1LyAINFfPv/p5KuJXvRjw3FJQFTkTTcFKHUKrLqAlWZdLeCM4MxBP2g551l+gZX3py0UIlv1EsJHCCL66WGFJzNmB7Z+rxJyLCvV+xWCBKic5Q= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.127sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <20080228005447.GM21674@Sun.COM> <47C6ED29.8010806@sun.com> <47D69F5E.2070903@sun.com> <20080311160608.GE62669@submonkey.net> <20080311190803.GH62669@submonkey.net> <20080311200245.GI62669@submonkey.net> Status: RO Content-Length: 5399 --Boundary_(ID_K1pgkwFmo6S/r8BzUq/hLw) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline [final revision, take two - /hopefully/] Someone pointed out a grammatical issue in the EXIT STATUS section. s/which/that/ 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 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 that are in the maintenance state or + are blocking other enabled services. --Boundary_(ID_K1pgkwFmo6S/r8BzUq/hLw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline [final revision, take two - /hopefully/]

Someone pointed out a grammatical issue in the EXIT STATUS section.  s/which/that/

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 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 that are in the maintenance state or
+            are blocking other enabled services.



--Boundary_(ID_K1pgkwFmo6S/r8BzUq/hLw)-- From liane.praza@sun.com Wed Mar 12 10:13:40 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2CHDeam023747 for ; Wed, 12 Mar 2008 10:13:40 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2CHDcZl008988 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 12 Mar 2008 10:13:40 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXM00K11NUR5300@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 12 Mar 2008 11:13:39 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXM00J2WNUR9610@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 12 Mar 2008 11:13:39 -0600 (MDT) Received: from [129.146.228.161] (nihil.SFBay.Sun.COM [129.146.228.161]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2CHDcA3220380; Wed, 12 Mar 2008 10:13:38 -0700 (PDT) Date: Wed, 12 Mar 2008 10:13:39 -0700 From: Liane Praza Subject: Re: 2008/159 svcs -xq In-reply-to: To: Mark Martin Cc: psarc-ext@sun.com, opensolaris-arc@opensolaris.org Message-id: <47D80F43.50106@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20080228005447.GM21674@Sun.COM> <47C6ED29.8010806@sun.com> <47D69F5E.2070903@sun.com> <20080311160608.GE62669@submonkey.net> <20080311190803.GH62669@submonkey.net> <20080311200245.GI62669@submonkey.net> User-Agent: Thunderbird 2.0.0.9 (X11/20080201) Status: RO Content-Length: 57 This case was approved during ARC business today. liane