From artem.kachitchkine@oracle.com Wed Jul 21 18:51:54 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6M1prgk003312 for ; Wed, 21 Jul 2010 18:51:53 -0700 (PDT) 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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6M1prMm012849 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 21 Jul 2010 18:51:53 -0700 (PDT) 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 <0L5X00K01RUHKR00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Jul 2010 18:51:53 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L5X0050ORUHH5B0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Jul 2010 18:51:53 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o6M1pqi8027297; Thu, 22 Jul 2010 01:51:52 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6M1ppAL020494; Thu, 22 Jul 2010 01:51:51 +0000 (GMT) Received: from abhmt006.oracle.com by acsmt354.oracle.com with ESMTP id 447722241279763479; Wed, 21 Jul 2010 18:51:19 -0700 Received: from [129.146.104.83] (/129.146.104.83) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Jul 2010 18:51:19 -0700 Date: Wed, 21 Jul 2010 18:52:09 -0700 From: Artem Kachitchkine Subject: PSARC/2010/283 SMF service for in.mpathd To: PSARC-ext@sun.com Cc: Mark Haywood Message-id: <4C47A449.8060608@oracle.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 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4C47A438.002D:SCFMA4539814,ss=1,fgs=0 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100524 Thunderbird/3.0.4 Status: RO Content-Length: 6874 I am sponsoring this fast-track for Mark Haywood. Minor binding is requested. Timeout is set for 07/29/2010. -Artem Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: SMF service for in.mpathd 1.2. Name of Document Author/Supplier: Author: Mark Haywood 1.3 Date of This Document: 21 July, 2010 4. Technical Description Overview -------- Today, in.mpathd(1m), the daemon that performs failure and repair detection for IP interfaces that have been placed into an IPMP group is started via fork(2)-exec(2) by ifconfig(1m) on-demand when an IPMP group is created (or by svc:/network/initial if all IP interfaces on the system are being monitored). The daemon is being run in environments where network robustness is a high priority. As such, having the daemon managed by SMF infrastructure and taking advantage of SMF's restarter facility seems like a better choice than the current ifconfig mechanism which cannot provide as high a level of availability of the daemon as SMF. The current design has already been problematic enough to have been addressed within the Sun Cluster consolidation. PSARC/2005/142 introduced an SMF service that manages in.mpathd on Sun Cluster systems. At the time that PSARC/2005/142 was presented, we resisted implementing an SMF service to manage in.mpathd as part of core Solaris because we felt that we needed to see how the Clearview IPMP rearchitecture panned out before doing this work. The Clearview IPMP rearchitecture has been completed and is no longer an issue. Additionally, a concern at the time was that in.mpathd was not an ideal fit for being managed by an SMF service because in.mpathd only needs to be running (enabled) when IPMP groups are configured on the system. This is still true. However, IPMP use by our customers has increased to the point that we now believe that over two-thirds of our Enterprise customers are running their systems with IPMP configured. Though the fit might not be perfect, there is no technical reason not to have in.mpathd controlled by an SMF service. Proposal -------- Replace the Sun Cluster consolidation SMF service introduced by PSARC/2005/142 with an ON consolidation service whose sole responsibility will be to ensure the availability of in.mpathd. The Sun Cluster group was notified. The contract associated with PSARC/2005/142 will be terminated. Details ------- in.mpathd will be managed by smf(5) under the service identifier, svc:/network/ipmp. The service will support a single instance, svc:/network/ipmp:default, that will be enabled by default and will support start, stop and refresh methods. solaris.smf.manage.ipmp authorization allows users to enable/disable the service and will be added to the Network Management execution profile. The SMF manifest for the service is included below. ifconfig will no longer fork(2)-exec(2) in.mpathd on-demand. The daemon should be running, unless the service was explicitly disabled by the administrator. In such cases, ifconfig will display warning messages when IPMP groups are created. Similarly, if the IPMP service is disabled while IPMP groups are configured, the service stop method will display warning messages to the console. To aid ifconfig in determining whether or not the service is running, a new interface will be added to the libipmp library, ipmp_is_svc_enabled(). The new interface will conform to the design as documented by PSARC/2007/272. Specifically, ipmp_is_svc_enabled() will return a newly introduced error code, IPMP_ESVCDISABLED. And ipmp_errmsg() will return an appropriate message for the new error code. The release binding for this project is Minor. Interfaces Exported: Interface | Classification | Comments --------------------------+-----------------+-------------------------- ipmp_is_svc_enabled | Project private | libipmp interface IPMP_ESVCDISABLED | Project private | libipmp error code svc:/network/ipmp:default | Committed | FMRI for the IPMP service Solaris.smf.manage.ipmp | Committed | action authorization for | | IPMP service --------------------------+-----------------+-------------------------- 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Darren.Moffat@oracle.com Thu Jul 22 01:26:54 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6M8QsZj006803 for ; Thu, 22 Jul 2010 01:26:54 -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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6M8QrjM017265 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 22 Jul 2010 01:26: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 <0L5Y00F0BA4TS000@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 01:26:53 -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 <0L5Y00BHYA4TTFA0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 01:26:53 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o6M8QqWt003270 for ; Thu, 22 Jul 2010 08:26:52 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6M59KM3025352 for ; Thu, 22 Jul 2010 08:26:51 +0000 (GMT) Received: from abhmt015.oracle.com by acsmt355.oracle.com with ESMTP id 448571381279787208; Thu, 22 Jul 2010 01:26:48 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Jul 2010 01:26:48 -0700 Date: Thu, 22 Jul 2010 09:26:45 +0100 From: Darren J Moffat Subject: Re: PSARC/2010/283 SMF service for in.mpathd In-reply-to: <4C47A449.8060608@oracle.com> To: Artem Kachitchkine Cc: PSARC-ext@sun.com, Mark Haywood Message-id: <4C4800C5.4010800@Oracle.COM> Organization: Oracle Solaris Security 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 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4C4800CC.0018:SCFMA4539814,ss=1,fgs=0 References: <4C47A449.8060608@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre3 Thunderbird/3.0.4 Status: RO Content-Length: 272 Looks reasonable to me, with one tiny comment: > exec='/lib/svc/method/net-ipmp %m' Given that in.mpathd is only really supposed to be started by the SMF service now why is a method script necessary why can't the exec method be in.mpathd itself ? -- Darren J Moffat From mark.haywood@oracle.com Thu Jul 22 06:27:08 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6MDR8Jh010446 for ; Thu, 22 Jul 2010 06:27:08 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6MDR7xi000266 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 22 Jul 2010 08:27:08 -0500 (CDT) 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 <0L5Y00C07O17EU00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 06:27:07 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L5Y002YRO17MC70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 06:27:07 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o6MDR7p6003640 for ; Thu, 22 Jul 2010 13:27:07 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6MDR50K006068 for ; Thu, 22 Jul 2010 13:27:05 +0000 (GMT) Received: from abhmt013.oracle.com by acsmt353.oracle.com with ESMTP id 427428861279805164; Thu, 22 Jul 2010 06:26:04 -0700 Received: from [129.148.174.28] (/129.148.174.28) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Jul 2010 06:26:03 -0700 Date: Thu, 22 Jul 2010 09:27:41 -0400 From: Mark Haywood Subject: Re: PSARC/2010/283 SMF service for in.mpathd In-reply-to: <4C4800C5.4010800@Oracle.COM> To: Darren J Moffat Cc: Artem Kachitchkine , PSARC-ext@sun.com Message-id: <4C48474D.9060706@oracle.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 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4C48472A.0186:SCFMA4539814,ss=1,fgs=0 References: <4C47A449.8060608@oracle.com> <4C4800C5.4010800@Oracle.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Thunderbird/3.0.1 Status: RO Content-Length: 502 On 07/22/10 04:26 AM, Darren J Moffat wrote: > Looks reasonable to me, with one tiny comment: > >> exec='/lib/svc/method/net-ipmp %m' > > Given that in.mpathd is only really supposed to be started by the SMF > service now why is a method script necessary why can't the exec method > be in.mpathd itself ? It could be. However, the stop method requires a script since we'd conditionally like to display a message on stop. For consistency sake, we'd like to use the script for all methods. Mark From Darren.Moffat@oracle.com Thu Jul 22 06:28:44 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6MDSiZf010463 for ; Thu, 22 Jul 2010 06:28:44 -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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6MDSiVe005757 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 22 Jul 2010 06:28:44 -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 <0L5Y00905O3WAB00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 06:28:44 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L5Y001TKO3VD780@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 06:28:43 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o6MDShHj017833 for ; Thu, 22 Jul 2010 13:28:43 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6M8LCV4014488 for ; Thu, 22 Jul 2010 13:28:42 +0000 (GMT) Received: from abhmt003.oracle.com by acsmt355.oracle.com with ESMTP id 449335921279805320; Thu, 22 Jul 2010 06:28:40 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Jul 2010 06:28:40 -0700 Date: Thu, 22 Jul 2010 14:28:37 +0100 From: Darren J Moffat Subject: Re: PSARC/2010/283 SMF service for in.mpathd In-reply-to: <4C48474D.9060706@oracle.com> To: Mark Haywood Cc: Artem Kachitchkine , PSARC-ext@sun.com Message-id: <4C484785.7000901@Oracle.COM> Organization: Oracle Solaris Security 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 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4C48478B.0044:SCFMA4539814,ss=1,fgs=0 References: <4C47A449.8060608@oracle.com> <4C4800C5.4010800@Oracle.COM> <4C48474D.9060706@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre3 Thunderbird/3.0.4 Status: RO Content-Length: 615 On 22/07/2010 14:27, Mark Haywood wrote: > On 07/22/10 04:26 AM, Darren J Moffat wrote: >> Looks reasonable to me, with one tiny comment: >> >>> exec='/lib/svc/method/net-ipmp %m' >> >> Given that in.mpathd is only really supposed to be started by the SMF >> service now why is a method script necessary why can't the exec method >> be in.mpathd itself ? > > It could be. However, the stop method requires a script since we'd > conditionally like to display a message on stop. For consistency sake, > we'd like to use the script for all methods. Where are you displaying the message and how ? -- Darren J Moffat From mark.haywood@oracle.com Thu Jul 22 06:35:11 2010 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 o6MDZAKl010588 for ; Thu, 22 Jul 2010 06:35:10 -0700 (PDT) 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.4) with ESMTP id o6MDZ98Z012719 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 22 Jul 2010 07:35:10 -0600 (MDT) 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 <0L5Y00C0JOEMRH00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 06:35:10 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L5Y002APOELMX80@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 06:35:09 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o6MDZ9Yn021574 for ; Thu, 22 Jul 2010 13:35:09 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6MDZ5EY028963 for ; Thu, 22 Jul 2010 13:35:06 +0000 (GMT) Received: from abhmt005.oracle.com by acsmt353.oracle.com with ESMTP id 449352541279805676; Thu, 22 Jul 2010 06:34:36 -0700 Received: from [129.148.174.28] (/129.148.174.28) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Jul 2010 06:34:36 -0700 Date: Thu, 22 Jul 2010 09:36:14 -0400 From: Mark Haywood Subject: Re: PSARC/2010/283 SMF service for in.mpathd In-reply-to: <4C484785.7000901@Oracle.COM> To: Darren J Moffat Cc: Artem Kachitchkine , PSARC-ext@sun.com Message-id: <4C48494E.2010900@oracle.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 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4C48490C.011B:SCFMA4539814,ss=1,fgs=0 References: <4C47A449.8060608@oracle.com> <4C4800C5.4010800@Oracle.COM> <4C48474D.9060706@oracle.com> <4C484785.7000901@Oracle.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Thunderbird/3.0.1 Status: RO Content-Length: 977 On 07/22/10 09:28 AM, Darren J Moffat wrote: > On 22/07/2010 14:27, Mark Haywood wrote: >> On 07/22/10 04:26 AM, Darren J Moffat wrote: >>> Looks reasonable to me, with one tiny comment: >>> >>>> exec='/lib/svc/method/net-ipmp %m' >>> >>> Given that in.mpathd is only really supposed to be started by the SMF >>> service now why is a method script necessary why can't the exec method >>> be in.mpathd itself ? >> >> It could be. However, the stop method requires a script since we'd >> conditionally like to display a message on stop. For consistency sake, >> we'd like to use the script for all methods. > > Where are you displaying the message and how ? > I'm making use of the smf_console() function: # smf_console # # Use as "echo message 2>&1 | smf_console". If SMF_MSGLOG_REDIRECT is # unset, message will be displayed to console. SMF_MSGLOG_REDIRECT is # reserved for future use. # smf_console () { /usr/bin/tee ${SMF_MSGLOG_REDIRECT:-/dev/msglog} } From Darren.Moffat@oracle.com Thu Jul 22 06:39:11 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6MDdBhs010609 for ; Thu, 22 Jul 2010 06:39:11 -0700 (PDT) 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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6MDdBbr022790 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 22 Jul 2010 06:39:11 -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 <0L5Y00409OLBO100@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 07:39:11 -0600 (MDT) 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 <0L5Y008P3OLA1CE0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 07:39:10 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o6MDdAAw021045 for ; Thu, 22 Jul 2010 13:39:10 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6MBbopX021914 for ; Thu, 22 Jul 2010 13:39:09 +0000 (GMT) Received: from abhmt009.oracle.com by acsmt354.oracle.com with ESMTP id 449367511279805940; Thu, 22 Jul 2010 06:39:00 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Jul 2010 06:38:59 -0700 Date: Thu, 22 Jul 2010 14:38:57 +0100 From: Darren J Moffat Subject: Re: PSARC/2010/283 SMF service for in.mpathd In-reply-to: <4C48494E.2010900@oracle.com> To: Mark Haywood Cc: Artem Kachitchkine , PSARC-ext@sun.com Message-id: <4C4849F1.2050204@Oracle.COM> Organization: Oracle Solaris Security 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 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4C4849FE.006F:SCFMA4539814,ss=1,fgs=0 References: <4C47A449.8060608@oracle.com> <4C4800C5.4010800@Oracle.COM> <4C48474D.9060706@oracle.com> <4C484785.7000901@Oracle.COM> <4C48494E.2010900@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre3 Thunderbird/3.0.4 Status: RO Content-Length: 966 On 22/07/2010 14:36, Mark Haywood wrote: > On 07/22/10 09:28 AM, Darren J Moffat wrote: >> On 22/07/2010 14:27, Mark Haywood wrote: >>> On 07/22/10 04:26 AM, Darren J Moffat wrote: >>>> Looks reasonable to me, with one tiny comment: >>>> >>>>> exec='/lib/svc/method/net-ipmp %m' >>>> >>>> Given that in.mpathd is only really supposed to be started by the SMF >>>> service now why is a method script necessary why can't the exec method >>>> be in.mpathd itself ? >>> >>> It could be. However, the stop method requires a script since we'd >>> conditionally like to display a message on stop. For consistency sake, >>> we'd like to use the script for all methods. >> >> Where are you displaying the message and how ? >> > I'm making use of the smf_console() function: Okay, now I'm wondering why that is appropriate for this stop method ? Why is this service so important that stopping it causes console messages ? What is the console message ? -- Darren J Moffat From mark.haywood@oracle.com Thu Jul 22 06:42:44 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6MDgiAV010641 for ; Thu, 22 Jul 2010 06:42:44 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6MDghEE006831 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 22 Jul 2010 08:42:44 -0500 (CDT) 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 <0L5Y00D07OR74D00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 06:42:43 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L5Y002QVOR6MC80@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 06:42:43 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o6MDggxJ022697 for ; Thu, 22 Jul 2010 13:42:42 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6MDgekK022371 for ; Thu, 22 Jul 2010 13:42:40 +0000 (GMT) Received: from abhmt019.oracle.com by acsmt355.oracle.com with ESMTP id 427479341279806118; Thu, 22 Jul 2010 06:41:58 -0700 Received: from [129.148.174.28] (/129.148.174.28) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Jul 2010 06:41:58 -0700 Date: Thu, 22 Jul 2010 09:43:37 -0400 From: Mark Haywood Subject: Re: PSARC/2010/283 SMF service for in.mpathd In-reply-to: <4C4849F1.2050204@Oracle.COM> To: Darren J Moffat Cc: Artem Kachitchkine , PSARC-ext@sun.com Message-id: <4C484B09.6020700@oracle.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 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4C484AD2.0012:SCFMA4539814,ss=1,fgs=0 References: <4C47A449.8060608@oracle.com> <4C4800C5.4010800@Oracle.COM> <4C48474D.9060706@oracle.com> <4C484785.7000901@Oracle.COM> <4C48494E.2010900@oracle.com> <4C4849F1.2050204@Oracle.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Thunderbird/3.0.1 Status: RO Content-Length: 1210 On 07/22/10 09:38 AM, Darren J Moffat wrote: > On 22/07/2010 14:36, Mark Haywood wrote: >> On 07/22/10 09:28 AM, Darren J Moffat wrote: >>> On 22/07/2010 14:27, Mark Haywood wrote: >>>> On 07/22/10 04:26 AM, Darren J Moffat wrote: >>>>> Looks reasonable to me, with one tiny comment: >>>>> >>>>>> exec='/lib/svc/method/net-ipmp %m' >>>>> >>>>> Given that in.mpathd is only really supposed to be started by the SMF >>>>> service now why is a method script necessary why can't the exec >>>>> method >>>>> be in.mpathd itself ? >>>> >>>> It could be. However, the stop method requires a script since we'd >>>> conditionally like to display a message on stop. For consistency sake, >>>> we'd like to use the script for all methods. >>> >>> Where are you displaying the message and how ? >>> >> I'm making use of the smf_console() function: > > Okay, now I'm wondering why that is appropriate for this stop method ? > Why is this service so important that stopping it causes console > messages ? > > What is the console message ? As mentioned in the case: "Similarly, if the IPMP service is disabled while IPMP groups are configured, the service stop method will display warning messages to the console." From Darren.Moffat@oracle.com Thu Jul 22 08:39:22 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6MFdM0j012810 for ; Thu, 22 Jul 2010 08:39:22 -0700 (PDT) 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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6MFdKiq015949 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 22 Jul 2010 08:39:22 -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 <0L5Y00E0NU5LO000@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 09:39:21 -0600 (MDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L5Y006X5U5LOT60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 09:39:21 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o6MFdKR4005017 for ; Thu, 22 Jul 2010 15:39:20 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6LHktpu015079 for ; Thu, 22 Jul 2010 15:39:19 +0000 (GMT) Received: from abhmt003.oracle.com by acsmt355.oracle.com with ESMTP id 427918411279813158; Thu, 22 Jul 2010 08:39:18 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Jul 2010 08:39:17 -0700 Date: Thu, 22 Jul 2010 16:39:09 +0100 From: Darren J Moffat Subject: Re: PSARC/2010/283 SMF service for in.mpathd In-reply-to: <4C484B09.6020700@oracle.com> To: Mark Haywood Cc: Artem Kachitchkine , PSARC-ext@sun.com Message-id: <4C48661D.8070909@Oracle.COM> Organization: Oracle Solaris Security 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 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4C486628.0073:SCFMA4539814,ss=1,fgs=0 References: <4C47A449.8060608@oracle.com> <4C4800C5.4010800@Oracle.COM> <4C48474D.9060706@oracle.com> <4C484785.7000901@Oracle.COM> <4C48494E.2010900@oracle.com> <4C4849F1.2050204@Oracle.COM> <4C484B09.6020700@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre3 Thunderbird/3.0.4 Status: RO Content-Length: 1277 On 22/07/2010 14:43, Mark Haywood wrote: >> Okay, now I'm wondering why that is appropriate for this stop method ? >> Why is this service so important that stopping it causes console >> messages ? Why is this service so much more important when it stops than any other service ? Will this message display on a normal (clean) shutdown of the whole system ? >> What is the console message ? > > As mentioned in the case: > > "Similarly, if the IPMP service is disabled while IPMP groups are > configured, the service stop method will display warning messages to the > console." Why is the console the appropriate place for this ? My concern is that most other SMF services that are "important" for system operation don't write on the console when they are stopped so why should this one ? If you stop network/physical:default it doesn't write to the console. If this service is so important that when it is stopped the admin be notified is a console message really the correct way. Maybe if there are IPMP groups configured (and running) the service shouldn't stop at all but instead go into maintenance mode if the admin attempts to stop it - that way existing monitoring systems that look for services in maintenance will alter the admin. -- Darren J Moffat From Nicolas.Williams@oracle.com Thu Jul 22 09:31:31 2010 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 o6MGVVTl014160 for ; Thu, 22 Jul 2010 09:31:31 -0700 (PDT) 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.4) with ESMTP id o6MGVUFw049084 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 22 Jul 2010 10:31:30 -0600 (MDT) 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 <0L5Y00L13WKI3F00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 09:31:30 -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 <0L5Y00IAWWKIST40@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 09:31:30 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o6MGVTlr026397 for ; Thu, 22 Jul 2010 16:31:29 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6MGVRbh010406 for ; Thu, 22 Jul 2010 16:31:28 +0000 (GMT) Received: from abhmt005.oracle.com by acsmt355.oracle.com with ESMTP id 449942331279816285; Thu, 22 Jul 2010 09:31:25 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Jul 2010 09:31:24 -0700 Date: Thu, 22 Jul 2010 11:31:36 -0500 From: Nicolas Williams Subject: Re: PSARC/2010/283 SMF service for in.mpathd In-reply-to: <4C484B09.6020700@oracle.com> To: Mark Haywood Cc: Darren J Moffat , Artem Kachitchkine , PSARC-ext@sun.com Message-id: <20100722163135.GB24773@oracle.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 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4C487260.01CC:SCFMA4539814,ss=1,fgs=0 References: <4C47A449.8060608@oracle.com> <4C4800C5.4010800@Oracle.COM> <4C48474D.9060706@oracle.com> <4C484785.7000901@Oracle.COM> <4C48494E.2010900@oracle.com> <4C4849F1.2050204@Oracle.COM> <4C484B09.6020700@oracle.com> User-Agent: Mutt/1.5.20 (2010-03-02) Status: RO Content-Length: 1703 On Thu, Jul 22, 2010 at 09:43:37AM -0400, Mark Haywood wrote: > >What is the console message ? > > As mentioned in the case: > > "Similarly, if the IPMP service is disabled while IPMP groups are > configured, the service stop method will display warning messages to > the console." This is useless: the user doing the stopping won't be on the console, and the message will be useless noise at shutdown time (since the service can't tell if a stop method invocation is for shutdown or some other purpose; see aside below). Besides, there are plenty of services that should be running when some feature is enabled, and which don't output such messages. For example, in.iked (if the output of ipsecconf -l shows protect rules then chances are you need in.iked running, and if you don't it's because you're using manually-keyed SAs, which is not a good idea). There are other examples (NFS? check. idmap? check. etcetera). Even if such a message were desirable, you could still have it be output by in.mpathd rather than having to create a stop method script. But just get rid of this message. [It might be nice if SMF could distinguish between kinds of service stops. Some services might care whether they are being stopped by a sysadmin, stopped as part of restarting, or stopped as part of shutting down the system. In the first case a service might well refuse to stop and have its stop method return an error, because not running when the service is absolutely necessary could result in a broken system. But that's not this case, and in.mpathd does not seem like case where preventing manual service stops is crucial. Though an RFE against SMF for this is probably a good idea.] Nico -- From mark.haywood@oracle.com Thu Jul 22 10:11:49 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6MHBnfr015145 for ; Thu, 22 Jul 2010 10:11:49 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6MHBn1V021774 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 22 Jul 2010 12:11:49 -0500 (CDT) 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 <0L5Y0080XYFO8N00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 10:11:48 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L5Y00G74YFNTBF0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 10:11:48 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o6MHBltg019821 for ; Thu, 22 Jul 2010 17:11:47 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6M9MbR5017799 for ; Thu, 22 Jul 2010 17:11:41 +0000 (GMT) Received: from abhmt015.oracle.com by acsmt353.oracle.com with ESMTP id 428230291279818644; Thu, 22 Jul 2010 10:10:44 -0700 Received: from [129.148.174.28] (/129.148.174.28) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Jul 2010 10:10:44 -0700 Date: Thu, 22 Jul 2010 13:12:23 -0400 From: Mark Haywood Subject: Re: PSARC/2010/283 SMF service for in.mpathd In-reply-to: <4C48661D.8070909@Oracle.COM> To: Darren J Moffat Cc: Artem Kachitchkine , PSARC-ext@sun.com Message-id: <4C487BF7.3090202@oracle.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 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4C487BD2.01A8:SCFMA4539814,ss=1,fgs=0 References: <4C47A449.8060608@oracle.com> <4C4800C5.4010800@Oracle.COM> <4C48474D.9060706@oracle.com> <4C484785.7000901@Oracle.COM> <4C48494E.2010900@oracle.com> <4C4849F1.2050204@Oracle.COM> <4C484B09.6020700@oracle.com> <4C48661D.8070909@Oracle.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Thunderbird/3.0.1 Status: RO Content-Length: 2598 On 07/22/10 11:39 AM, Darren J Moffat wrote: > On 22/07/2010 14:43, Mark Haywood wrote: >>> Okay, now I'm wondering why that is appropriate for this stop method ? >>> Why is this service so important that stopping it causes console >>> messages ? > > Why is this service so much more important when it stops than any > other service ? You're assigning importance here. I believe that an administrator that is disabling the service when IPMP groups are configured, probably is making a mistake is should be warned. That said, your comments below have merit. > > Will this message display on a normal (clean) shutdown of the whole > system ? No. > >>> What is the console message ? >> >> As mentioned in the case: >> >> "Similarly, if the IPMP service is disabled while IPMP groups are >> configured, the service stop method will display warning messages to the >> console." > > Why is the console the appropriate place for this ? If all we are going to do is provide a message, then the console would be a better choice for getting immediate attention. But if we put the service into maintenance mode as you suggest, then the service log would be more appropriate. > > My concern is that most other SMF services that are "important" for > system operation don't write on the console when they are stopped so > why should this one ? If you stop network/physical:default it > doesn't write to the console. True. > > If this service is so important that when it is stopped the admin be > notified is a console message really the correct way. > > Maybe if there are IPMP groups configured (and running) the service > shouldn't stop at all but instead go into maintenance mode if the > admin attempts to stop it - that way existing monitoring systems that > look for services in maintenance will alter the admin. > A good suggestion. However, that means that there is no way for an administrator to disable the service unless all IPMP groups have been destroyed. That does not seem unreasonable to me. So having the service transition into maintenance mode and writing a message to the service log might be the right way to go. But if that's the case, then I think ifconfig should likewise prevent the creation of IPMP groups if the service is not enabled. Again, this seems reasonable to me. Getting back to your original question, 'why is a method script necessary why can't the exec method be in.mpathd itself?" The answer is still the same. Because there is more complex logic involved in the stop method and we'd like to be consistent across all methods. Mark From ceri@submonkey.net Thu Jul 22 11:40:25 2010 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 o6MIeODm016688 for ; Thu, 22 Jul 2010 11:40:24 -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.4) with ESMTP id o6MIeNt0053882 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 22 Jul 2010 12:40:24 -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 <0L5Z003032JBJC00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 11:40:23 -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 <0L5Z00GCM2JB3J20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 11:40:23 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o6MIbVCx028239 for ; Thu, 22 Jul 2010 18:40:22 +0000 (GMT) Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay41i.sun.com with ESMTP id BT-MMP-63130 for PSARC-ext@sun.com; Thu, 22 Jul 2010 18:40:18 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-39122444 for PSARC-ext@sun.com; Thu, 22 Jul 2010 18:40:18 +0000 (Z) Received: from scuttle.submonkey.net ([208.111.43.184] [208.111.43.184]) by relay4i.sun.com with ESMTP id BT-MMP-2963467 for PSARC-ext@sun.com; Thu, 22 Jul 2010 18:40:17 +0000 (Z) Received: from cpc6-cdif11-2-0-cust58.know.cable.virginmedia.com ([62.255.146.59] helo=shrike.submonkey.net) by scuttle.submonkey.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Oc0gn-0005Rf-21; Thu, 22 Jul 2010 18:40:14 +0000 Received: from ceri by shrike.submonkey.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Oc0gk-0002kU-Mh; Thu, 22 Jul 2010 19:40:10 +0100 Date: Thu, 22 Jul 2010 19:40:10 +0100 From: Ceri Davies Subject: Re: PSARC/2010/283 SMF service for in.mpathd In-reply-to: <4C47A449.8060608@oracle.com> Sender: Ceri Davies To: Artem Kachitchkine Cc: PSARC-ext@sun.com, Mark Haywood Message-id: <20100722184010.GA71989@submonkey.net> 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 X-Brightmail-Tracker: AAAAAA== X-PGP: finger ceri@FreeBSD.org X-Antispam: No, score=-2.6/5.0, scanned in 0.172sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4C47A449.8060608@oracle.com> User-Agent: Mutt/1.5.20 (2009-06-14) Status: RO Content-Length: 6278 On Wed, Jul 21, 2010 at 06:52:09PM -0700, Artem Kachitchkine wrote: > I am sponsoring this fast-track for Mark Haywood. Minor binding is > requested. Timeout is set for 07/29/2010. > > -Artem > > Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI > This information is Copyright (c) 2010, Oracle and/or its affiliates. > All rights reserved. > 1. Introduction > 1.1. Project/Component Working Name: > SMF service for in.mpathd > 1.2. Name of Document Author/Supplier: > Author: Mark Haywood > 1.3 Date of This Document: > 21 July, 2010 > 4. Technical Description > > Overview > -------- > Today, in.mpathd(1m), the daemon that performs failure and repair > detection for IP interfaces that have been placed into an IPMP group > is started via fork(2)-exec(2) by ifconfig(1m) on-demand when an IPMP > group is created (or by svc:/network/initial if all IP interfaces on > the system are being monitored). The daemon is being run in > environments where network robustness is a high priority. As such, > having the daemon managed by SMF infrastructure and taking advantage > of SMF's restarter facility seems like a better choice than the current > ifconfig mechanism which cannot provide as high a level of availability > of the daemon as SMF. > > The current design has already been problematic enough to have been > addressed within the Sun Cluster consolidation. PSARC/2005/142 > introduced an SMF service that manages in.mpathd on Sun Cluster > systems. At the time that PSARC/2005/142 was presented, we resisted > implementing an SMF service to manage in.mpathd as part of core Solaris > because we felt that we needed to see how the Clearview IPMP > rearchitecture panned out before doing this work. The Clearview IPMP > rearchitecture has been completed and is no longer an issue. > Additionally, a concern at the time was that in.mpathd was not an ideal > fit for being managed by an SMF service because in.mpathd only needs to > be running (enabled) when IPMP groups are configured on the system. > This is still true. However, IPMP use by our customers has increased > to the point that we now believe that over two-thirds of our Enterprise > customers are running their systems with IPMP configured. Though the > fit might not be perfect, there is no technical reason not to have > in.mpathd controlled by an SMF service. > > Proposal > -------- > Replace the Sun Cluster consolidation SMF service introduced by > PSARC/2005/142 with an ON consolidation service whose sole > responsibility will be to ensure the availability of in.mpathd. > The Sun Cluster group was notified. The contract associated with > PSARC/2005/142 will be terminated. > > Details > ------- > in.mpathd will be managed by smf(5) under the service identifier, > svc:/network/ipmp. The service will support a single instance, > svc:/network/ipmp:default, that will be enabled by default and will > support start, stop and refresh methods. > > solaris.smf.manage.ipmp authorization allows users to enable/disable > the service and will be added to the Network Management execution > profile. The SMF manifest for the service is included below. > > > > name='network/ipmp' > type='service' > version='1'> > > > > > > name='network' > grouping='optional_all' > restart_on='none' > type='service'> > > > > type='method' > name='start' > exec='/lib/svc/method/net-ipmp %m' > timeout_seconds='60'> > > > > > > type='method' > name='stop' > exec='/lib/svc/method/net-ipmp %m' > timeout_seconds='60'> > > > > > > type='method' > name='refresh' > exec='/lib/svc/method/net-ipmp %m' > timeout_seconds='60'> > > > > > > > > value='solaris.smf.manage.ipmp' /> > value='solaris.smf.manage.ipmp' /> > > > > > > > > > > ifconfig will no longer fork(2)-exec(2) in.mpathd on-demand. The daemon > should be running, unless the service was explicitly disabled by the > administrator. In such cases, ifconfig will display warning messages > when IPMP groups are created. Similarly, if the IPMP service is > disabled while IPMP groups are configured, the service stop method will > display warning messages to the console. Does this also obviate 'adopt' (and any other) mode? If not, where is the property? Also, I'd expect the SMF to deprecate /etc/default/mpathd in favour of properties; is that a future case? Ceri -- Haffely, Gaffely, Gaffely, Gonward. From mark.haywood@oracle.com Thu Jul 22 13:42:31 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6MKgVuM019021 for ; Thu, 22 Jul 2010 13:42:31 -0700 (PDT) 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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6MKgVSp019079 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 22 Jul 2010 13:42:31 -0700 (PDT) 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 <0L5Z00A0586VUO00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 13:42:31 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L5Z004V786UXW50@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 13:42:30 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o6MKgU2w018230 for ; Thu, 22 Jul 2010 20:42:30 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6MKgQk5022591; Thu, 22 Jul 2010 20:42:26 +0000 (GMT) Received: from abhmt021.oracle.com by acsmt355.oracle.com with ESMTP id 428790331279831283; Thu, 22 Jul 2010 13:41:23 -0700 Received: from [129.148.174.28] (/129.148.174.28) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Jul 2010 13:41:23 -0700 Date: Thu, 22 Jul 2010 16:43:01 -0400 From: Mark Haywood Subject: Re: PSARC/2010/283 SMF service for in.mpathd In-reply-to: <20100722184010.GA71989@submonkey.net> To: Ceri Davies Cc: Artem Kachitchkine , PSARC-ext@sun.com Message-id: <4C48AD55.5060101@oracle.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 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4C48AD34.007D:SCFMA4539814,ss=1,fgs=0 References: <4C47A449.8060608@oracle.com> <20100722184010.GA71989@submonkey.net> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Thunderbird/3.0.1 Status: RO Content-Length: 7309 > > On Wed, Jul 21, 2010 at 06:52:09PM -0700, Artem Kachitchkine wrote: > >> I am sponsoring this fast-track for Mark Haywood. Minor binding is >> requested. Timeout is set for 07/29/2010. >> >> -Artem >> >> Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI >> This information is Copyright (c) 2010, Oracle and/or its affiliates. >> All rights reserved. >> 1. Introduction >> 1.1. Project/Component Working Name: >> SMF service for in.mpathd >> 1.2. Name of Document Author/Supplier: >> Author: Mark Haywood >> 1.3 Date of This Document: >> 21 July, 2010 >> 4. Technical Description >> >> Overview >> -------- >> Today, in.mpathd(1m), the daemon that performs failure and repair >> detection for IP interfaces that have been placed into an IPMP group >> is started via fork(2)-exec(2) by ifconfig(1m) on-demand when an IPMP >> group is created (or by svc:/network/initial if all IP interfaces on >> the system are being monitored). The daemon is being run in >> environments where network robustness is a high priority. As such, >> having the daemon managed by SMF infrastructure and taking advantage >> of SMF's restarter facility seems like a better choice than the current >> ifconfig mechanism which cannot provide as high a level of availability >> of the daemon as SMF. >> >> The current design has already been problematic enough to have been >> addressed within the Sun Cluster consolidation. PSARC/2005/142 >> introduced an SMF service that manages in.mpathd on Sun Cluster >> systems. At the time that PSARC/2005/142 was presented, we resisted >> implementing an SMF service to manage in.mpathd as part of core Solaris >> because we felt that we needed to see how the Clearview IPMP >> rearchitecture panned out before doing this work. The Clearview IPMP >> rearchitecture has been completed and is no longer an issue. >> Additionally, a concern at the time was that in.mpathd was not an ideal >> fit for being managed by an SMF service because in.mpathd only needs to >> be running (enabled) when IPMP groups are configured on the system. >> This is still true. However, IPMP use by our customers has increased >> to the point that we now believe that over two-thirds of our Enterprise >> customers are running their systems with IPMP configured. Though the >> fit might not be perfect, there is no technical reason not to have >> in.mpathd controlled by an SMF service. >> >> Proposal >> -------- >> Replace the Sun Cluster consolidation SMF service introduced by >> PSARC/2005/142 with an ON consolidation service whose sole >> responsibility will be to ensure the availability of in.mpathd. >> The Sun Cluster group was notified. The contract associated with >> PSARC/2005/142 will be terminated. >> >> Details >> ------- >> in.mpathd will be managed by smf(5) under the service identifier, >> svc:/network/ipmp. The service will support a single instance, >> svc:/network/ipmp:default, that will be enabled by default and will >> support start, stop and refresh methods. >> >> solaris.smf.manage.ipmp authorization allows users to enable/disable >> the service and will be added to the Network Management execution >> profile. The SMF manifest for the service is included below. >> >> >> >> > name='network/ipmp' >> type='service' >> version='1'> >> >> >> >> >> >> > name='network' >> grouping='optional_all' >> restart_on='none' >> type='service'> >> >> >> >> > type='method' >> name='start' >> exec='/lib/svc/method/net-ipmp %m' >> timeout_seconds='60'> >> >> >> >> >> >> > type='method' >> name='stop' >> exec='/lib/svc/method/net-ipmp %m' >> timeout_seconds='60'> >> >> >> >> >> >> > type='method' >> name='refresh' >> exec='/lib/svc/method/net-ipmp %m' >> timeout_seconds='60'> >> >> >> >> >> >> >> >> > value='solaris.smf.manage.ipmp' /> >> > value='solaris.smf.manage.ipmp' /> >> >> >> >> >> >> >> >> >> >> ifconfig will no longer fork(2)-exec(2) in.mpathd on-demand. The daemon >> should be running, unless the service was explicitly disabled by the >> administrator. In such cases, ifconfig will display warning messages >> when IPMP groups are created. Similarly, if the IPMP service is >> disabled while IPMP groups are configured, the service stop method will >> display warning messages to the console. >> > Does this also obviate 'adopt' (and any other) mode? If not, where is > the property? > Yes. 'adopt' was really intended to start in.mpathd in case ifconfig failed to do so at boottime (hearkens back to split between / and /usr and in.mpathd linking libraries dynamically). This is no longer necessary. Is there some reason that you think 'adopt' is needed? > Also, I'd expect the SMF to deprecate /etc/default/mpathd in favour of > properties; is that a future case? > Yes, it will most likely be a future case. We're not sure that a straight conversion from /etc/default/mpathd to SMF properties is the right thing to do. We believe we might want to support some of the properties (FAILURE_DETECTION_TIME and FAILBACK), as well as some new properties, on a per-group basis in the future. They are likely to be SMF properties in the future, but whether or not they will be SMF properties of this service remains the be seen. But likely not. In any case, obsoleting /etc/default/mpathd isn't a requirement for this case. Mark > Ceri > From ceri@submonkey.net Thu Jul 22 16:06:56 2010 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 o6MN6uAh021413 for ; Thu, 22 Jul 2010 16:06:56 -0700 (PDT) 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.4) with ESMTP id o6MN6toV037519 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 22 Jul 2010 17:06:56 -0600 (MDT) 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 <0L5Z00I05EVJYA00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 16:06:55 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L5Z0041AEVJXPC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 16:06:55 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o6MN6sZP005895 for ; Thu, 22 Jul 2010 23:06:55 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay41i.sun.com with ESMTP id BT-MMP-73352 for PSARC-ext@sun.com; Thu, 22 Jul 2010 23:04:54 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-39408328 for PSARC-ext@sun.com; Thu, 22 Jul 2010 23:04:54 +0000 (Z) Received: from scuttle.submonkey.net ([208.111.43.184] [208.111.43.184]) by relay4i.sun.com with ESMTP id BT-MMP-3525142 for PSARC-ext@sun.com; Thu, 22 Jul 2010 23:04:52 +0000 (Z) Received: from cpc6-cdif11-2-0-cust58.know.cable.virginmedia.com ([62.255.146.59] helo=shrike.submonkey.net) by scuttle.submonkey.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Oc4ou-0003Ce-8E; Thu, 22 Jul 2010 23:04:52 +0000 Received: from ceri by shrike.submonkey.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Oc4os-000DGY-0R; Fri, 23 Jul 2010 00:04:50 +0100 Date: Fri, 23 Jul 2010 00:04:49 +0100 From: Ceri Davies Subject: Re: PSARC/2010/283 SMF service for in.mpathd In-reply-to: <4C48AD55.5060101@oracle.com> Sender: Ceri Davies To: Mark Haywood Cc: Artem Kachitchkine , PSARC-ext@sun.com Message-id: <20100722230449.GB71989@submonkey.net> 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 X-Brightmail-Tracker: AAAAAA== X-PGP: finger ceri@FreeBSD.org X-Antispam: No, score=0.0/5.0, scanned in 0.115sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4C47A449.8060608@oracle.com> <20100722184010.GA71989@submonkey.net> <4C48AD55.5060101@oracle.com> User-Agent: Mutt/1.5.20 (2009-06-14) Status: RO Content-Length: 1768 On Thu, Jul 22, 2010 at 04:43:01PM -0400, Mark Haywood wrote: > Ceri Davies wrote: > > On Wed, Jul 21, 2010 at 06:52:09PM -0700, Artem Kachitchkine wrote: > >> > >> ifconfig will no longer fork(2)-exec(2) in.mpathd on-demand. The daemon > >> should be running, unless the service was explicitly disabled by the > >> administrator. In such cases, ifconfig will display warning messages > >> when IPMP groups are created. Similarly, if the IPMP service is > >> disabled while IPMP groups are configured, the service stop method will > >> display warning messages to the console. > >> > > Does this also obviate 'adopt' (and any other) mode? If not, where is > > the property? > > > > Yes. 'adopt' was really intended to start in.mpathd in case ifconfig > failed to do so at boottime (hearkens back to split between / and /usr > and in.mpathd linking libraries dynamically). This is no longer > necessary. Is there some reason that you think 'adopt' is needed? No, that's fine, thanks. > > Also, I'd expect the SMF to deprecate /etc/default/mpathd in favour of > > properties; is that a future case? > > > > Yes, it will most likely be a future case. We're not sure that a > straight conversion from /etc/default/mpathd to SMF properties is the > right thing to do. We believe we might want to support some of the > properties (FAILURE_DETECTION_TIME and FAILBACK), as well as some new > properties, on a per-group basis in the future. They are likely to be > SMF properties in the future, but whether or not they will be SMF > properties of this service remains the be seen. But likely not. In any > case, obsoleting /etc/default/mpathd isn't a requirement for this case. Works for me, thanks. Ceri -- Haffely, Gaffely, Gaffely, Gonward. From mark.haywood@oracle.com Thu Jul 22 20:14:06 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6N3E6Gf025831 for ; Thu, 22 Jul 2010 20:14:06 -0700 (PDT) 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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6N3E5k2024595 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 22 Jul 2010 20:14:06 -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 <0L5Z00701QBHPP00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 21:14:05 -0600 (MDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L5Z007S4QBH4400@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 21:14:05 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o6N3E4FB011569 for ; Fri, 23 Jul 2010 03:14:04 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6MK3qMi022963 for ; Fri, 23 Jul 2010 03:14:03 +0000 (GMT) Received: from abhmt017.oracle.com by acsmt353.oracle.com with ESMTP id 451354101279854827; Thu, 22 Jul 2010 20:13:47 -0700 Received: from [129.148.19.14] (/129.148.19.14) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Jul 2010 20:13:44 -0700 Date: Thu, 22 Jul 2010 23:13:36 -0400 From: Mark Haywood Subject: Re: PSARC/2010/283 SMF service for in.mpathd In-reply-to: <20100722163135.GB24773@oracle.com> To: Nicolas Williams Cc: Darren J Moffat , Artem Kachitchkine , PSARC-ext@sun.com Message-id: <4C4908E0.3000205@oracle.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 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4C4908FC.0155:SCFMA4539814,ss=1,fgs=0 References: <4C47A449.8060608@oracle.com> <4C4800C5.4010800@Oracle.COM> <4C48474D.9060706@oracle.com> <4C484785.7000901@Oracle.COM> <4C48494E.2010900@oracle.com> <4C4849F1.2050204@Oracle.COM> <4C484B09.6020700@oracle.com> <20100722163135.GB24773@oracle.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080310) Status: RO Content-Length: 2178 Nicolas Williams wrote: > On Thu, Jul 22, 2010 at 09:43:37AM -0400, Mark Haywood wrote: > >>> What is the console message ? >>> >> As mentioned in the case: >> >> "Similarly, if the IPMP service is disabled while IPMP groups are >> configured, the service stop method will display warning messages to >> the console." >> > > This is useless: the user doing the stopping won't be on the console, > and the message will be useless noise at shutdown time (since the > service can't tell if a stop method invocation is for shutdown or some > other purpose; see aside below). > > Besides, there are plenty of services that should be running when some > feature is enabled, and which don't output such messages. For example, > in.iked (if the output of ipsecconf -l shows protect rules then chances > are you need in.iked running, and if you don't it's because you're using > manually-keyed SAs, which is not a good idea). There are other examples > (NFS? check. idmap? check. etcetera). > Agreed. And after looking at other services and investigating transitioning into maintenance mode when the service is disabled, I believe that the best course of action is simply to get rid of the message. Switching into maintenance mode would require the user to unconfigure all IPMP groups to get back out of maintenance mode. This is not acceptable. Mark > Even if such a message were desirable, you could still have it be output > by in.mpathd rather than having to create a stop method script. But > just get rid of this message. > > [It might be nice if SMF could distinguish between kinds of service > stops. Some services might care whether they are being stopped by a > sysadmin, stopped as part of restarting, or stopped as part of shutting > down the system. In the first case a service might well refuse to stop > and have its stop method return an error, because not running when the > service is absolutely necessary could result in a broken system. But > that's not this case, and in.mpathd does not seem like case where > preventing manual service stops is crucial. Though an RFE against SMF > for this is probably a good idea.] > > Nico > From girish.moodalbail@oracle.com Thu Jul 22 21:36:33 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6N4aXff027097 for ; Thu, 22 Jul 2010 21:36:33 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6N4aWhQ016184 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 22 Jul 2010 23:36:32 -0500 (CDT) 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 <0L5Z00H05U4WL300@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 21:36:32 -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 <0L5Z00HZKU4W8XB0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 21:36:32 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o6N4aVrQ006037 for ; Fri, 23 Jul 2010 04:36:32 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6N4aTnU016244 for ; Fri, 23 Jul 2010 04:36:29 +0000 (GMT) Received: from abhmt021.oracle.com by acsmt353.oracle.com with ESMTP id 451460921279859710; Thu, 22 Jul 2010 21:35:10 -0700 Received: from [10.7.250.55] (/10.7.250.55) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Jul 2010 21:35:09 -0700 Date: Thu, 22 Jul 2010 23:35:07 -0500 From: Girish Moodalbail Subject: Re: PSARC/2010/283 SMF service for in.mpathd In-reply-to: <4C47A449.8060608@oracle.com> To: Artem Kachitchkine Cc: PSARC-ext@sun.com, Mark Haywood Message-id: <4C491BFB.3080705@oracle.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 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4C491C4F.011B:SCFMA4539814,ss=1,fgs=0 References: <4C47A449.8060608@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 3752 On 07/21/10 08:52 PM, Artem Kachitchkine wrote: > I am sponsoring this fast-track for Mark Haywood. Minor binding is > requested. Timeout is set for 07/29/2010. > > -Artem > > Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI > This information is Copyright (c) 2010, Oracle and/or its affiliates. > All rights reserved. > 1. Introduction > 1.1. Project/Component Working Name: > SMF service for in.mpathd > 1.2. Name of Document Author/Supplier: > Author: Mark Haywood > 1.3 Date of This Document: > 21 July, 2010 > 4. Technical Description > > Overview > -------- > Today, in.mpathd(1m), the daemon that performs failure and repair > detection for IP interfaces that have been placed into an IPMP group > is started via fork(2)-exec(2) by ifconfig(1m) on-demand when an IPMP > group is created (or by svc:/network/initial if all IP interfaces on > the system are being monitored). The daemon is being run in > environments where network robustness is a high priority. As such, > having the daemon managed by SMF infrastructure and taking advantage > of SMF's restarter facility seems like a better choice than the current > ifconfig mechanism which cannot provide as high a level of availability > of the daemon as SMF. > > The current design has already been problematic enough to have been > addressed within the Sun Cluster consolidation. PSARC/2005/142 > introduced an SMF service that manages in.mpathd on Sun Cluster > systems. At the time that PSARC/2005/142 was presented, we resisted > implementing an SMF service to manage in.mpathd as part of core Solaris > because we felt that we needed to see how the Clearview IPMP > rearchitecture panned out before doing this work. The Clearview IPMP > rearchitecture has been completed and is no longer an issue. > Additionally, a concern at the time was that in.mpathd was not an ideal > fit for being managed by an SMF service because in.mpathd only needs to > be running (enabled) when IPMP groups are configured on the system. > This is still true. However, IPMP use by our customers has increased > to the point that we now believe that over two-thirds of our Enterprise > customers are running their systems with IPMP configured. Though the > fit might not be perfect, there is no technical reason not to have > in.mpathd controlled by an SMF service. > > Proposal > -------- > Replace the Sun Cluster consolidation SMF service introduced by > PSARC/2005/142 with an ON consolidation service whose sole > responsibility will be to ensure the availability of in.mpathd. > The Sun Cluster group was notified. The contract associated with > PSARC/2005/142 will be terminated. > > Details > ------- > in.mpathd will be managed by smf(5) under the service identifier, > svc:/network/ipmp. The service will support a single instance, > svc:/network/ipmp:default, that will be enabled by default and will > support start, stop and refresh methods. > > solaris.smf.manage.ipmp authorization allows users to enable/disable > the service and will be added to the Network Management execution > profile. The SMF manifest for the service is included below. > > > > name='network/ipmp' > type='service' > version='1'> > > > > > > name='network' > grouping='optional_all' > restart_on='none' > type='service'> > > Mark, Had a quick clarification question on the dependency you have specified above for the new svc:/network/ipmp. Don't we need this daemon much before we reach the milestone/networ? I mean, while re-configuring IPMP interfaces during boot from net-physical script? thanks ~Girish From mark.haywood@oracle.com Thu Jul 22 21:53:13 2010 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 o6N4rDPD027216 for ; Thu, 22 Jul 2010 21:53:13 -0700 (PDT) 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.4) with ESMTP id o6N4rDAM050818 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 22 Jul 2010 22:53:13 -0600 (MDT) 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 <0L5Z00G03UWP3B00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 21:53:13 -0700 (PDT) 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 <0L5Z001GLUWOENC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Jul 2010 21:53:12 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o6N4rCg9026678 for ; Fri, 23 Jul 2010 04:53:12 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6N0WNmh013625 for ; Fri, 23 Jul 2010 04:53:11 +0000 (GMT) Received: from abhmt015.oracle.com by acsmt355.oracle.com with ESMTP id 451487491279860773; Thu, 22 Jul 2010 21:52:53 -0700 Received: from [129.148.19.14] (/129.148.19.14) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Jul 2010 21:52:53 -0700 Date: Fri, 23 Jul 2010 00:52:51 -0400 From: Mark Haywood Subject: Re: PSARC/2010/283 SMF service for in.mpathd In-reply-to: <4C491BFB.3080705@oracle.com> To: Girish Moodalbail Cc: Artem Kachitchkine , PSARC-ext@sun.com Message-id: <4C492023.50601@oracle.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 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4C492038.0003:SCFMA4539814,ss=1,fgs=0 References: <4C47A449.8060608@oracle.com> <4C491BFB.3080705@oracle.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080310) Status: RO Content-Length: 4579 Girish Moodalbail wrote: > On 07/21/10 08:52 PM, Artem Kachitchkine wrote: >> I am sponsoring this fast-track for Mark Haywood. Minor binding is >> requested. Timeout is set for 07/29/2010. >> >> -Artem >> >> Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI >> This information is Copyright (c) 2010, Oracle and/or its affiliates. >> All rights reserved. >> 1. Introduction >> 1.1. Project/Component Working Name: >> SMF service for in.mpathd >> 1.2. Name of Document Author/Supplier: >> Author: Mark Haywood >> 1.3 Date of This Document: >> 21 July, 2010 >> 4. Technical Description >> >> Overview >> -------- >> Today, in.mpathd(1m), the daemon that performs failure and repair >> detection for IP interfaces that have been placed into an IPMP group >> is started via fork(2)-exec(2) by ifconfig(1m) on-demand when an IPMP >> group is created (or by svc:/network/initial if all IP interfaces on >> the system are being monitored). The daemon is being run in >> environments where network robustness is a high priority. As such, >> having the daemon managed by SMF infrastructure and taking advantage >> of SMF's restarter facility seems like a better choice than the current >> ifconfig mechanism which cannot provide as high a level of availability >> of the daemon as SMF. >> >> The current design has already been problematic enough to have been >> addressed within the Sun Cluster consolidation. PSARC/2005/142 >> introduced an SMF service that manages in.mpathd on Sun Cluster >> systems. At the time that PSARC/2005/142 was presented, we resisted >> implementing an SMF service to manage in.mpathd as part of core Solaris >> because we felt that we needed to see how the Clearview IPMP >> rearchitecture panned out before doing this work. The Clearview IPMP >> rearchitecture has been completed and is no longer an issue. >> Additionally, a concern at the time was that in.mpathd was not an ideal >> fit for being managed by an SMF service because in.mpathd only needs to >> be running (enabled) when IPMP groups are configured on the system. >> This is still true. However, IPMP use by our customers has increased >> to the point that we now believe that over two-thirds of our Enterprise >> customers are running their systems with IPMP configured. Though the >> fit might not be perfect, there is no technical reason not to have >> in.mpathd controlled by an SMF service. >> >> Proposal >> -------- >> Replace the Sun Cluster consolidation SMF service introduced by >> PSARC/2005/142 with an ON consolidation service whose sole >> responsibility will be to ensure the availability of in.mpathd. >> The Sun Cluster group was notified. The contract associated with >> PSARC/2005/142 will be terminated. >> >> Details >> ------- >> in.mpathd will be managed by smf(5) under the service identifier, >> svc:/network/ipmp. The service will support a single instance, >> svc:/network/ipmp:default, that will be enabled by default and will >> support start, stop and refresh methods. >> >> solaris.smf.manage.ipmp authorization allows users to enable/disable >> the service and will be added to the Network Management execution >> profile. The SMF manifest for the service is included below. >> >> >> >> > name='network/ipmp' >> type='service' >> version='1'> >> >> >> >> >> >> > name='network' >> grouping='optional_all' >> restart_on='none' >> type='service'> >> >> > > Mark, > > Had a quick clarification question on the dependency you have > specified above for the new svc:/network/ipmp. Don't we need this > daemon much before we reach the milestone/networ? I mean, while > re-configuring IPMP interfaces during boot from net-physical script? It is possible that the dependencies may have to change once I do some further testing. I did not mean to imply by including the service example in the case, that the dependency list was set in stone. That said, I'm not sure that in.mpathd has to start before net-physical. In fact, as was mentioned earlier in this thread, in.mpathd today supports an 'adopt' option that was supposed to handle the case where in.mpathd cannot be executed during net-physical. The option is for historical reasons and should not be relevant any longer. In any case, as things stand, IPMP groups can be created before in.mpathd is running so I think the answer to your question at this point is no. Mark > > thanks > ~Girish From Darren.Moffat@Oracle.COM Fri Jul 23 02:15:27 2010 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 o6N9FRRC028278 for ; Fri, 23 Jul 2010 02:15:27 -0700 (PDT) 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.4) with ESMTP id o6N9FQBv036354 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 23 Jul 2010 03:15:27 -0600 (MDT) 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 <0L6000I0971RQT00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 23 Jul 2010 03:15:27 -0600 (MDT) 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 <0L60004OA71QJ5B0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 23 Jul 2010 03:15:26 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o6N9FQvq013284 for ; Fri, 23 Jul 2010 09:15:26 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6N91Knt025522 for ; Fri, 23 Jul 2010 09:15:24 +0000 (GMT) Received: from abhmt021.oracle.com by acsmt354.oracle.com with ESMTP id 452007391279876522; Fri, 23 Jul 2010 02:15:22 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Jul 2010 02:15:21 -0700 Date: Fri, 23 Jul 2010 10:15:18 +0100 From: Darren J Moffat Subject: Re: PSARC/2010/283 SMF service for in.mpathd In-reply-to: <4C4908E0.3000205@oracle.com> To: Mark Haywood Cc: Nicolas Williams , Artem Kachitchkine , PSARC-ext@sun.com Message-id: <4C495DA6.5050109@Oracle.COM> Organization: Oracle Solaris Security 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 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4C495DAD.023E:SCFMA4539814,ss=1,fgs=0 References: <4C47A449.8060608@oracle.com> <4C4800C5.4010800@Oracle.COM> <4C48474D.9060706@oracle.com> <4C484785.7000901@Oracle.COM> <4C48494E.2010900@oracle.com> <4C4849F1.2050204@Oracle.COM> <4C484B09.6020700@oracle.com> <20100722163135.GB24773@oracle.com> <4C4908E0.3000205@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre3 Thunderbird/3.0.4 Status: RO Content-Length: 655 On 23/07/2010 04:13, Mark Haywood wrote: > Agreed. And after looking at other services and investigating > transitioning into maintenance mode when the service is disabled, I > believe that the best course of action is simply to get rid of the > message. Switching into maintenance mode would require the user to > unconfigure all IPMP groups to get back out of maintenance mode. This is > not acceptable. Thanks, I have no further comments on the case and it gets my +1 with the original spec modified to remove the console message. I agree with Mark that the dependencies are an implementation issue not an ARC interface issue. -- Darren J Moffat From sebastien.roy@oracle.com Fri Jul 23 06:46:42 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6NDkgb5001075 for ; Fri, 23 Jul 2010 06:46:42 -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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6NDkfx9002234 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 23 Jul 2010 06:46:41 -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 <0L6000K0PJLT4000@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 23 Jul 2010 07:46:41 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L600017WJLRAGD0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 23 Jul 2010 07:46:40 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o6NDkdxB018868 for ; Fri, 23 Jul 2010 13:46:39 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6MHYsGT000321 for ; Fri, 23 Jul 2010 13:46:37 +0000 (GMT) Received: from abhmt017.oracle.com by acsmt355.oracle.com with ESMTP id 431049941279892702; Fri, 23 Jul 2010 06:45:02 -0700 Received: from [129.148.174.103] (/129.148.174.103) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Jul 2010 06:45:01 -0700 Date: Fri, 23 Jul 2010 09:45:00 -0400 From: Sebastien Roy Subject: Re: PSARC/2010/283 SMF service for in.mpathd In-reply-to: <4C4908E0.3000205@oracle.com> To: Mark Haywood Cc: Nicolas Williams , Darren J Moffat , Artem Kachitchkine , PSARC-ext@sun.com Message-id: <4C499CDC.70002@oracle.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 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A0B0205.4C499D3E.007D:SCFMA4539814,ss=1,fgs=0 References: <4C47A449.8060608@oracle.com> <4C4800C5.4010800@Oracle.COM> <4C48474D.9060706@oracle.com> <4C484785.7000901@Oracle.COM> <4C48494E.2010900@oracle.com> <4C4849F1.2050204@Oracle.COM> <4C484B09.6020700@oracle.com> <20100722163135.GB24773@oracle.com> <4C4908E0.3000205@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.10) Gecko/20100621 Lightning/1.0b1 Thunderbird/3.0.5 Status: RO Content-Length: 1450 On 07/22/10 11:13 PM, Mark Haywood wrote: > Nicolas Williams wrote: >> On Thu, Jul 22, 2010 at 09:43:37AM -0400, Mark Haywood wrote: >>>> What is the console message ? >>> As mentioned in the case: >>> >>> "Similarly, if the IPMP service is disabled while IPMP groups are >>> configured, the service stop method will display warning messages to >>> the console." >> >> This is useless: the user doing the stopping won't be on the console, >> and the message will be useless noise at shutdown time (since the >> service can't tell if a stop method invocation is for shutdown or some >> other purpose; see aside below). >> >> Besides, there are plenty of services that should be running when some >> feature is enabled, and which don't output such messages. For example, >> in.iked (if the output of ipsecconf -l shows protect rules then chances >> are you need in.iked running, and if you don't it's because you're using >> manually-keyed SAs, which is not a good idea). There are other examples >> (NFS? check. idmap? check. etcetera). > > Agreed. And after looking at other services and investigating > transitioning into maintenance mode when the service is disabled, I > believe that the best course of action is simply to get rid of the > message. Switching into maintenance mode would require the user to > unconfigure all IPMP groups to get back out of maintenance mode. This is > not acceptable. That sounds fine to me. +1 on the case. -Seb From artem.kachitchkine@oracle.com Thu Jul 29 17:08:25 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6U08Pxh024939 for ; Thu, 29 Jul 2010 17:08:25 -0700 (PDT) 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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6U08O1C006100 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 29 Jul 2010 17:08:25 -0700 (PDT) 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 <0L6C00J0BGE13V00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Jul 2010 17:08:25 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L6C00IVVGE01P40@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Jul 2010 17:08:24 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o6U08Opd020602 for ; Fri, 30 Jul 2010 00:08:24 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6THPYBe030055 for ; Fri, 30 Jul 2010 00:08:23 +0000 (GMT) Received: from abhmt003.oracle.com by acsmt355.oracle.com with ESMTP id 469592281280448471; Thu, 29 Jul 2010 17:07:51 -0700 Received: from [129.146.104.83] (/129.146.104.83) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Jul 2010 17:07:50 -0700 Date: Thu, 29 Jul 2010 17:09:02 -0700 From: Artem Kachitchkine Subject: Re: PSARC/2010/283 SMF service for in.mpathd In-reply-to: <4C47A449.8060608@oracle.com> To: PSARC-ext@sun.com Cc: Mark Haywood Message-id: <4C52181E.7060603@oracle.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 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4C5217F8.0083:SCFMA4539814,ss=1,fgs=0 References: <4C47A449.8060608@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100524 Thunderbird/3.0.4 Status: RO Content-Length: 22 The case is approved.