Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Dec 2011 21:03:23 -0800
From:      Doug Barton <dougb@FreeBSD.org>
To:        Maxim Ignatenko <gelraen.ua@gmail.com>
Cc:        freebsd-rc@freebsd.org
Subject:   Re: conf/163508: [rc.subr] [patch] Add &quot; enable&quot; and &quot; disable&quot; commands to rc.subr
Message-ID:  <4EF9519B.8090409@FreeBSD.org>
In-Reply-To: <CABWTX-Z8g7Tom8dJSH2Q=Hq38qy=WFdhtwzmSeoLe=jig9Mzaw@mail.gmail.com>
References:  <201112241230.pBOCUF3h064098@freefall.freebsd.org> <D9E8E12B-7E7F-4164-802F-4F6FE7DFB397@bsdimp.com> <4EF64915.4030006@FreeBSD.org> <DE3E9178-9610-4014-AABA-32C66823C1B8@bsdimp.com> <4EF8105D.3030907@FreeBSD.org> <CABWTX-Z9aPJpwdjOz6ZXRykGpDC0sJW0wpSAwr=pZpnL1Qwm6g@mail.gmail.com> <4EF90CE7.7050008@FreeBSD.org> <CABWTX-Z8g7Tom8dJSH2Q=Hq38qy=WFdhtwzmSeoLe=jig9Mzaw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 12/26/2011 20:36, Maxim Ignatenko wrote:
> On 27 December 2011 02:10, Doug Barton <dougb@freebsd.org> wrote:
>> On 12/26/2011 09:26, Maxim Ignatenko wrote:
>>> On 26 December 2011 08:12, Doug Barton <dougb@freebsd.org> 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/




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EF9519B.8090409>