From owner-freebsd-rc@FreeBSD.ORG Mon Dec 26 07:00:36 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 B39031065675; Mon, 26 Dec 2011 07:00:36 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5A9BE8FC12; Mon, 26 Dec 2011 07:00:36 +0000 (UTC) Received: by yhfq46 with SMTP id q46so8307137yhf.13 for ; Sun, 25 Dec 2011 23:00:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=OYHggqPl9e9gQ0dShy+VwehidCLhsknMGVis7g2vj9U=; b=EwCVu3qpWzdfD6IkIVanbELiruF7KRhXfslCxZ/1FbJlzs8YbdJF7ixBAYqWbfNpI2 EyyHPLCpIhWrxtknz3EZwWNlhv/K9xe/aXoIitLxCsY9x4Eh8fNfN5rYlU3Zd86z1S21 hu8ZSofBQ82VlL7JOylcN7xuIilRuSMzzeEdc= Received: by 10.236.127.144 with SMTP id d16mr32140873yhi.51.1324882835651; Sun, 25 Dec 2011 23:00:35 -0800 (PST) Received: from [192.168.2.4] (dpc691944246.direcpc.com. [69.19.44.246]) by mx.google.com with ESMTPS id d5sm33487099yhl.19.2011.12.25.23.00.23 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 25 Dec 2011 23:00:34 -0800 (PST) References: <201112241230.pBOCUF3h064098@freefall.freebsd.org> <4EF64915.4030006@FreeBSD.org> <4EF8105D.3030907@FreeBSD.org> In-Reply-To: <4EF8105D.3030907@FreeBSD.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <286B56F0-CD3B-4B1C-A5DE-45BC2CAFEB89@gmail.com> X-Mailer: iPhone Mail (9A405) From: Garrett Cooper Date: Sun, 25 Dec 2011 23:00:09 -0800 To: Doug Barton Cc: Maxim Ignatenko , "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: Mon, 26 Dec 2011 07:00:36 -0000 On Dec 25, 2011, at 10:12 PM, Doug Barton wrote: > On 12/24/2011 15:08, Warner Losh wrote: >>=20 >> On Dec 24, 2011, at 2:50 PM, Doug Barton wrote: >>=20 >>> 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... >>>=20 >>> Warner, >>>=20 >>> 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." >>=20 >> 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. >=20 > You do get that the OP included a patch, right? >=20 >>> 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. >>=20 >> Most people call that a bug, or at least POLA. The few cases in the >> tree where bar_enable=3Dyes forces foo_enable=3Dyes can be dealt with. >=20 > 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 files > 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. >=20 >>> For better or worse rc.d offers a lot of flexibility in how >>> services are enabled. We've already heard from users who use those >>> various mechanisms, and don't want them removed/broken. Absent an >>> overhaul of the underlying structure of configuration files (which >>> would violate one or both of remove/break existing functionality) >>> there is no way to add this feature in a thorough manner. Adding it >>> in a less-than-thorough manner will cause more problems than it >>> solves. >>=20 >> We should encourage others solving the problem completely. >=20 > IMO that's pie in the sky. >=20 >>> Which returns me to my original point, how hard is it to edit >>> rc.conf anyway? >>=20 >> Scripts would greatly benefit from having a robust way to do things >> without humans in the loop. >=20 > I'm not convinced that's a feature, but I'm willing to be persuaded. >=20 >> Some folks also would find it easier. >=20 > Once again, I think you're missing my point. I didn't say that I don't > *like* the idea. I think it would be awesome for us to have something > like this. My point is that we've already spent quite a lot of cycles > discussing how it could be done robustly, and discovered that at this > time it's not really possible to do that. >=20 >> Basically, we shouldn't get in the way here by telling people it >> can't be done. Then we get nothing. >>=20 >> Telling people to try is better. Worst thing that happens is that >> this effort fails. Best outcome is that they fix the issues to make >> it robust. >=20 > And worst outcome is that we waste a lot of time that could be put into > more productive areas; and screw over our users in the process. While a > good/interesting idea, this feature would be a "nice to have" at best. >=20 > My bottom line is that if you (Warner) or some group of committers want > to commit to: >=20 > 1. Rigorous testing (including *all* of the various possible > combinations of *conf* files) > 2. Short term support for users who are negatively impacted by any > changes you make > 3. Long term support of the code (and by long term I mean at least a few > months past the release of FreeBSD 10.1) >=20 > Then I say "go for it." Short of that level of commitment you're just > creating a big mess and then expecting other people to clean it up. Using multiple rc.conf files is an advanced feature. IMO, the same constrain= ts for Devin Teske's sysrc tool should apply here: 1. The tool will only work with one rc.conf file. 2. Simple rc.conf declarations are allowed, but evaluated statements can't a= nd won't be handled by the script/infrastructure. Once the caveats are documented and understood, we should have the bases cov= ered, s.t. this will handle the majority of the valid cases that the patch i= s attempting to address. Thanks, -Garrett=