Date: Mon, 26 Dec 2011 16:10:15 -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 " enable" and " disable" commands to rc.subr Message-ID: <4EF90CE7.7050008@FreeBSD.org> In-Reply-To: <CABWTX-Z9aPJpwdjOz6ZXRykGpDC0sJW0wpSAwr=pZpnL1Qwm6g@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 4. User is confused. Doug -- [^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?4EF90CE7.7050008>