From owner-freebsd-rc@FreeBSD.ORG Tue Dec 27 05:03:24 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 2C8561065670 for ; Tue, 27 Dec 2011 05:03:24 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id CF01314E0BD; Tue, 27 Dec 2011 05:03:23 +0000 (UTC) Message-ID: <4EF9519B.8090409@FreeBSD.org> Date: Mon, 26 Dec 2011 21:03:23 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Maxim Ignatenko References: <201112241230.pBOCUF3h064098@freefall.freebsd.org> <4EF64915.4030006@FreeBSD.org> <4EF8105D.3030907@FreeBSD.org> <4EF90CE7.7050008@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-rc@freebsd.org Subject: Re: conf/163508: [rc.subr] [patch] Add " enable" and " disable" commands to rc.subr X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 05:03:24 -0000 On 12/26/2011 20:36, Maxim Ignatenko wrote: > On 27 December 2011 02:10, Doug Barton wrote: >> On 12/26/2011 09:26, Maxim Ignatenko wrote: >>> On 26 December 2011 08:12, Doug Barton wrote: >>>> On 12/24/2011 15:08, Warner Losh wrote: >>>>> >>>>> On Dec 24, 2011, at 2:50 PM, Doug Barton wrote: >>>>> >>>>>> On 12/24/2011 08:46, Warner Losh wrote: >>>>>>> Also, let's not reject it before it is done. Let's reject it >>>>>>> when it actually doesn't handle the cases that are interesting. >>>>>>> No sense in cutting off a good feature because of some >>>>>>> theoretical problem. It is a problem we have sometimes in the >>>>>>> project... >>>>>> >>>>>> Warner, >>>>>> >>>>>> You seemed to have missed the bit where I said, "We've already been >>>>>> down this path once before, and it turns out to be way harder to do >>>>>> this right than it looks at first glance." >>>>> >>>>> No, I get that totally. I just don't care. The fact that others >>>>> have failed shouldn't mean we should discourage others from trying. >>>>> We shouldn't be shooting arrows at people before they are given a >>>>> chance to produce something good or bad, or when they do shooting >>>>> them without evaluating their work. >>>> >>>> You do get that the OP included a patch, right? >>>> >>>>>> Just as an example of potential problems, imagine a scenario where >>>>>> the user has foo_enable=NO in rc.conf, but the service keeps >>>>>> starting up anyway. >>>>> >>>>> Most people call that a bug, or at least POLA. The few cases in the >>>>> tree where bar_enable=yes forces foo_enable=yes can be dealt with. >>>> >>>> No, you seem to be missing my point. Because of the way that rc.d >>>> processes the various *conf* options the last match "wins." So let's say >>>> that you had foo_enable=0 in /etc/rc.conf; but one of the conf files >>>> that's processed later has foo_enable=1. If that's the last match, it >>>> gets started. This is one of the many concerns regarding trying to >>>> automatically enable or disable things. >>>> >>> >>> Proposed patch searches all files (except /etc/defaults/rc.conf) that >>> are included by load_rc_config() in _reverse_ order, so even if there >>> are some other files included in rc.conf, >> >> It's unusual, but not impossible for files to actually be included in >> /etc/rc.conf. What I think you're referring to is the files included by >> rc.d. >> >>> foo_enable=NO gets added to >>> the end of last processed file and we still have foo enabled. >> >> I reviewed your patch, I understand how it works. I still think you're >> missing my concern. Imagine this scenario: >> >> 1. foo gets enabled by something (a port, whatever). >> 2. User notices that foo is enabled, doesn't understand why, and adds >> "foo_enable=no" to /etc/rc.conf. >> 3. Because foo_enable=yes is in a conf file other than /etc/rc.conf, >> which is included later, it gets started again on next reboot. > > By default, there are only 2 files included after /etc/rc.conf: > /etc/rc.conf.local and /etc/rc.conf.d/${name}. Or you meant some other > files included manually (from where?)? How many files are necessary to make the scenario I described confusing? -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/