On 27 December 2011 07:03, Doug Barton <[email protected]> wrote: > On 12/26/2011 20:36, Maxim Ignatenko wrote: >> On 27 December 2011 02:10, Doug Barton <[email protected]> wrote: >>> On 12/26/2011 09:26, Maxim Ignatenko wrote: >>>> On 26 December 2011 08:12, Doug Barton <[email protected]> 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? _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-rc To unsubscribe, send any mail to "[email protected]"
