From owner-freebsd-rc@FreeBSD.ORG Fri Dec 23 21:14:48 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id A4EE3106564A; Fri, 23 Dec 2011 21:14:48 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 4BABE14EE47; Fri, 23 Dec 2011 21:14:48 +0000 (UTC) Message-ID: <4EF4EF48.9010503@FreeBSD.org> Date: Fri, 23 Dec 2011 13:14:48 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Eygene Ryabinkin References: <4EC6C9A4.3000006@delphij.net> <3EG8fAEe6lZEtr/D6Pw60YTcoYU@YnbH/K3/Y1Z96RV2jTofcGuSPJI> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Pyun Yong-Hyeon , freebsd-rc@freebsd.org, Garrett Cooper , Gleb Smirnoff , d@delphij.net Subject: Re: Annoying ERROR: 'wlan0' is not a DHCP-enabled interface 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: Fri, 23 Dec 2011 21:14:48 -0000 Short version, my opinion has not changed, there is no bug. On 12/23/2011 06:42, Eygene Ryabinkin wrote: > Resurrecting this old thread I abandoned due to the ENOTIME and adding > to CC all people who were expressed interest in fixing the annoyances > from the devd caused by r226879. > > Sun, Nov 20, 2011 at 12:41:22PM +0300, Mike Telahun Makonnen wrote: >>> I would say that my (ab)use of it in the patch perfectly fits the >>> cited usage. That's not an excuse if the semantics of rc_quiet will >>> be different from its current usage, but since we have no >>> well-documented semantics apart from "Don't output some diagnostics" >>> inside /etc/rc.subr, may be we can just extend this explanation based >>> on the current usage and the common sense, add that to the manual page >>> of rc.subr and go on? >>> >>> Any thoughts on this? >> >> The rc_quiet knob was introduced to prevent devd spamming the console >> when starting services that weren't enabled in rc.conf. It was also >> overloaded to prevent unnecessary boot time clutter on the console. >> The rationale was that if you set a service to start during boot you >> don't want a gazillion "bar started" messages to cause the one "Error: >> foo not started" message that you would really be interested in seeing >> to scroll out of the screen buffer. It was used for this purpose in >> several scripts in rc.d, but it caused quite a ruckus at the time (and >> I was too distracted by other work to continue working on it) so its >> use was mostly removed from the scripts under /etc/rc.d. > > OK, what about the following patch that documents the current usage of > the "quiet" prefix and enables dhclient to recognize this modifier? > Diff is available from > http://codelabs.ru/fbsd/patches/dhclient/dhclient-respect-quiet-mode.diff > > Since the current rc.subr script has the following snippet, > {{{ > if [ -n "${rcvar}" -a "$rc_arg" != "rcvar" -a "$rc_arg" != "stop" ] || > [ -n "${rcvar}" -a "$rc_arg" = "stop" -a -z "${rc_pid}" ]; then > if ! checkyesno ${rcvar}; then > if [ -n "${rc_quiet}" ]; then > return 0 > fi > echo -n "Cannot '${rc_arg}' $name. Set ${rcvar} to " > echo -n "YES in /etc/rc.conf or use 'one${rc_arg}' " > echo "instead of '${rc_arg}'." > return 0 > fi > fi > }}} You're misunderstanding the purpose of the above code. It's there so that you can do 'service foo stop' even if foo_enable is not set. > I think that error message about non-DHCP-enabled interface falls into the > same category It does not. > -- we have no "dhcp" modifier inside rc.conf, so we will fail > loudly, unless we were asked to be quiet, just as in the above code. > >> It was not intended to mask "error" or "debug" messages. > > It is not my intention as well: I care about masking only certain classes > of error and informational messages with rc_quiet; my patch to rc.subr.8 > documents all current cases where it is appropriate. Our opinions differ on this point. > It is the > internal problem of the devd that spams the first group of people So adjust devd.conf. -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/