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

[Maxim Ignatenko]

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?)?