From owner-freebsd-rc@FreeBSD.ORG Tue Dec 27 18:17:07 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B6031065670; Tue, 27 Dec 2011 18:17:07 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 12DE48FC14; Tue, 27 Dec 2011 18:17:06 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so16264963vbb.13 for ; Tue, 27 Dec 2011 10:17:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=g0MJC/0CxnNQH9bOTiuXxTfuYqFj2no2guXN0nbFIrU=; b=mvdjf9I3tw9W5FAz1hIUeW0ukmOj3Vv87VEiIBgk/7JSh14dFOvXdwr0GwKjrGN3qt P2PrS59jGuXoDT86WpbUrD/o/bYnUFc50CCTwqGQobBmYRoIspwSXC6c/zOF+vFo/sCd QR2DoedoZfOWPkjiQ3sE1lsevA6Vq635bSqrA= Received: by 10.52.27.20 with SMTP id p20mr3350070vdg.59.1325009826419; Tue, 27 Dec 2011 10:17:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.29.225 with HTTP; Tue, 27 Dec 2011 10:16:46 -0800 (PST) In-Reply-To: <4EF9519B.8090409@FreeBSD.org> References: <201112241230.pBOCUF3h064098@freefall.freebsd.org> <4EF64915.4030006@FreeBSD.org> <4EF8105D.3030907@FreeBSD.org> <4EF90CE7.7050008@FreeBSD.org> <4EF9519B.8090409@FreeBSD.org> From: Maxim Ignatenko Date: Tue, 27 Dec 2011 20:16:46 +0200 Message-ID: To: Doug Barton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-rc@freebsd.org Subject: Re: conf/163508: [rc.subr] [patch] Add " enable" and " disable" commands to rc.subr X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 18:17:07 -0000 On 27 December 2011 07:03, Doug Barton wrote: > On 12/26/2011 20:36, Maxim Ignatenko wrote: >> On 27 December 2011 02:10, Doug Barton wrote: >>> On 12/26/2011 09:26, Maxim Ignatenko wrote: >>>> On 26 December 2011 08:12, Doug Barton 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 =C2=A0it before it is done. =C2=A0Let's rej= ect 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. =C2=A0It is a problem we have sometimes in th= e >>>>>>>> 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. =C2=A0I just don't care. =C2=A0The 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=3DNO in rc.conf, but the service keeps >>>>>>> starting up anyway. >>>>>> >>>>>> Most people call that a bug, or at least POLA. =C2=A0The few cases i= n the >>>>>> tree where bar_enable=3Dyes forces foo_enable=3Dyes can be dealt wit= h. >>>>> >>>>> 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=3D0 in /etc/rc.conf; but one of the conf file= s >>>>> that's processed later has foo_enable=3D1. 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=3DNO 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=3Dno" to /etc/rc.conf. >>> 3. Because foo_enable=3Dyes 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?