From owner-freebsd-rc@FreeBSD.ORG Sat Dec 24 11:21:18 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 E5C39106564A; Sat, 24 Dec 2011 11:21:18 +0000 (UTC) (envelope-from rea@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 6E1FC8FC1F; Sat, 24 Dec 2011 11:21:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codelabs.ru; s=two; h=Sender:In-Reply-To:Content-Type:MIME-Version:Message-ID:Subject:Cc:To:From:Date; bh=mJVqS+HSWFnMewxgd4QyUJ/fYHhKTMF5/1/kzUxuH6w=; b=Kx8eIc+7QspRYyeMGPIaxyMS1XNhh7ElNMOnzih1mIApPs1XrGXI07ACZxmK7Bh26zwwkcgbCL071GOq4acSMedbkk9388x4jRSUMRQqaYJXR/HRQgbwQNotJphgoq+uCeL2Qda+4nXzM3ypTwsYRxubvhL71sBsroUJkucLmpBfxOE82hSbRJewmLPgII7YzAf+fKvD8fTqkqW2mzmDfuMTQ2+KHkOCewc6XpRRhkMHWYT1CM6Y/pKc5NrYcsl13o9oh3OQlXLtlYr4Rx9F9BKVEkTJnm8TPz2Z9UhpFfhsWae1t/TfesKmGbFuT5AM3ziVXNWglt5pw4ybjYnmQg==; Received: from shadow.codelabs.ru (ppp91-77-164-86.pppoe.mtu-net.ru [91.77.164.86]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1RePfA-000J12-NQ; Sat, 24 Dec 2011 14:21:17 +0300 Date: Sat, 24 Dec 2011 15:21:11 +0400 From: Eygene Ryabinkin To: Doug Barton Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline In-Reply-To: <4EF589DF.9060606@FreeBSD.org> <4EF4EF48.9010503@FreeBSD.org> Sender: rea@codelabs.ru 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: Sat, 24 Dec 2011 11:21:19 -0000 --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Doug, *, good day. Fri, Dec 23, 2011 at 01:14:48PM -0800, Doug Barton wrote: > > Since the current rc.subr script has the following snippet, > > {{{ > > if [ -n "${rcvar}" -a "$rc_arg" !=3D "rcvar" -a "$rc_ar= g" !=3D "stop" ] || > > [ -n "${rcvar}" -a "$rc_arg" =3D "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 'on= e${rc_arg}' " > > echo "instead of '${rc_arg}'." > > return 0 > > fi > > fi > > }}} >=20 > 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. Huh? OK, let's translate this code snippet to the human language. Here we go: - if 'rcvar' is not empty and the command is not 'rcvar' (that just shows the current and default status of the corresponding rc.conf variable) and the command is not 'stop' OR - if 'rcvar' is not empty and the command is 'stop' and ("but" in the human language) we have no PID for the daemon then we will bail out silently if rc_quiet is set or will print an error message and bail out. Soo, yes -- it allows us to do the 'stop' even if the service is disabled, but only if we really have the daemon running. But I am not talking about the purpose of the condition, I am talking about the semantics of the rc_quiet. And to talk about the semantics we should invert you assertion (that more-or-less correctly states when the code inside the outer 'if' clause is not executed and rc.d script will continue its operations) and to count the cases when we will enter the body of the outer 'if' statement. And it boils to every other case, but the ones cited above. In most cases, rc_quiet in this snippet will be consulted when the service won't be enabled in rc.conf; I think you won't be telling that I am wrong here? Moreover, as Mike (mtm@) explained, the "quiet" keyword was invented precisely to keep devd stuff to be silent: {{{ 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. }}} > > I think that error message about non-DHCP-enabled interface falls > > into the same category=20 >=20 > It does not. Please, explain your point here. (*) > >> It was not intended to mask "error" or "debug" messages. > >=20 > > It is not my intention as well: I care about masking only certain class= es > > of error and informational messages with rc_quiet; my patch to rc.subr.8 > > documents all current cases where it is appropriate. >=20 > Our opinions differ on this point. I think that our opinions differ at the word "appropriate", but not on the whole assertion of mine. Am I correct? > > It is the internal problem of the devd that spams the first group > > of people >=20 > So adjust devd.conf. Well, as the initial rationale of having the 'quiet' prefix was to quieten the devd stuff (and it is really quiet -- if you will glance over /etc/devd.conf, you will see that is just starts/stops the stuff upon events and doesn't care if the corresponding service is enabled; the dhclient culprit was just in additional rc.conf item -- "dhcp" in the interface configuration, if we would talk only about dhclient_enabled variable, there will be no current thread -- the case when it is not enabled _already_ handled by the /etc/rc.subr. So, in my view, you should either explain me the point where I have the faulty logics (as I had asked in this email, 5 paragraphs above, marked as '(*)') or the rc.subr snipped we're talking about should be freed from the check of rc_quiet status and the error message must be printed every time. Please, note, I am using "should" not to oblige you to do what I am saying, but just to express my thoughts about this semantical problem. Sat, Dec 24, 2011 at 12:14:23AM -0800, Doug Barton wrote: > On 12/24/2011 00:06, Gleb Smirnoff wrote: > > Do you suggest to adjust devd.conf in svn, or do you think that > > zillions of server FreeBSD installations should modify the default > > devd.conf to get rid of this spamming?=20 >=20 > There are zillions of FreeBSD servers with wlan interfaces? Excuse me, but you seem to hadn't glanced over the /etc/devd.conf. Dhclient is called on all appropriate interface types, not only for 802.11 ones: {{{ # # Try to start dhclient on Ethernet-like interfaces when the link comes # up. Only devices that are configured to support DHCP will actually # run it. No link down rule exists because dhclient automatically exits # when the link goes down. # notify 0 { match "system" "IFNET"; match "type" "LINK_UP"; media-type "ethernet"; action "/etc/rc.d/dhclient quietstart $subsystem"; }; notify 0 { match "system" "IFNET"; match "type" "LINK_UP"; media-type "802.11"; action "/etc/rc.d/dhclient quietstart $subsystem"; }; }}} And, I bet, there are zillions of FreeBSD servers with Ethernet interfaces for some sane definition of "zillion" as applied to the FreeBSD community. In other words, the majority of FreeBSD servers are running Ethernet interfaces and every 'ifup' event will result in the spam from the devd(8). --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --17pEHd4RhPHOinZp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iF4EAREIAAYFAk71tacACgkQFq+eroFS7PuzGAD9GdYd3ZWMCu9u3Lx5jcyAhKBW lA6cBIm402bs2CpmuFEBAJadWen9zD1lmkcha2CiBgS/3RzLiGr/cyk3oqXjWAje =G/tC -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp--