conf/163508: [rc.subr] [patch] Add " enable" and " disable" commands to rc.subr

[Maxim Ignatenko]

On 27 December 2011 07:03, Doug Barton <dougb at freebsd.org> wrote:
> On 12/26/2011 20:36, Maxim Ignatenko wrote:
>> On 27 December 2011 02:10, Doug Barton <dougb at freebsd.org> wrote:
>>> On 12/26/2011 09:26, Maxim Ignatenko wrote:
>>>> On 26 December 2011 08:12, Doug Barton <dougb at 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?
>

By default, /etc/rc.conf.d and /etc/rc.conf.local doesn't exists and
all changes will be done in /etc/rc.conf. If some of those exists,
user should be aware of it anyway. So, what exactly will be confusing?