From owner-freebsd-rc@FreeBSD.ORG Sun Dec 25 00:11:49 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 909BD106566C; Sun, 25 Dec 2011 00:11:49 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 08B598FC0A; Sun, 25 Dec 2011 00:11:48 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pBP0BlcT009837; Sun, 25 Dec 2011 04:11:47 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pBP0Bl4N009836; Sun, 25 Dec 2011 04:11:47 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sun, 25 Dec 2011 04:11:47 +0400 From: Gleb Smirnoff To: Garrett Cooper Message-ID: <20111225001147.GA8035@glebius.int.ru> References: <4EC6C9A4.3000006@delphij.net> <3EG8fAEe6lZEtr/D6Pw60YTcoYU@YnbH/K3/Y1Z96RV2jTofcGuSPJI> <4EF4EF48.9010503@FreeBSD.org> <20111224080617.GM80057@glebius.int.ru> <4EF589DF.9060606@FreeBSD.org> <20111224132924.GN80057@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Pyun Yong-Hyeon , Doug Barton , freebsd-rc@FreeBSD.org, Eygene Ryabinkin , d@delphij.net, Mike Telahun Makonnen 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: Sun, 25 Dec 2011 00:11:49 -0000 On Sat, Dec 24, 2011 at 11:02:17AM -0800, Garrett Cooper wrote: G> 2011/12/24 Gleb Smirnoff : G> > On Sat, Dec 24, 2011 at 12:14:23AM -0800, Doug Barton wrote: G> > D> On 12/24/2011 00:06, Gleb Smirnoff wrote: G> > D> > Do you suggest to adjust devd.conf in svn, or do you think that G> > D> > zillions of server FreeBSD installations should modify the default G> > D> > devd.conf to get rid of this spamming? G> > D> G> > D> There are zillions of FreeBSD servers with wlan interfaces? G> > G> > Current code spams console for any interfaces. G> G> Is that because of... G> G> console.info /var/log/console.log Okay, it would spam /var/log/messages. Or maybe you'd suggedt to shut it there, too? Any message about DHCP is absolutely irrelevent, and thus annoying on a box running static IP configuration. Disabling logging of entire syslog faclity is not a solution. -- Totus tuus, Glebius. From owner-freebsd-rc@FreeBSD.ORG Sun Dec 25 01:55:13 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 89C461065670; Sun, 25 Dec 2011 01:55:05 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 583108FC12; Sun, 25 Dec 2011 01:55:05 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so8986899obb.13 for ; Sat, 24 Dec 2011 17:55:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=xI04NPQun+JIQGZyX6qx1AyKrtlvthR15WtntToBCF4=; b=CffyxWtuDtydc18oJ5LK6H5LN3IwtVM/9klPM1M8lGTIEfREkozfXHdBTrbuXpuJop 8L07fLIlwwT+km+xByb8o3oHr/nfNw4QiXFc6tE/DGyrl7VnND7qrzChuww6Y8up8pe4 YZOlP0TaoDgaMHkckFAnOcPADZJls952NjWPg= MIME-Version: 1.0 Received: by 10.182.159.70 with SMTP id xa6mr17834842obb.1.1324778103959; Sat, 24 Dec 2011 17:55:03 -0800 (PST) Received: by 10.182.152.6 with HTTP; Sat, 24 Dec 2011 17:55:03 -0800 (PST) In-Reply-To: <20111225001147.GA8035@glebius.int.ru> References: <4EC6C9A4.3000006@delphij.net> <3EG8fAEe6lZEtr/D6Pw60YTcoYU@YnbH/K3/Y1Z96RV2jTofcGuSPJI> <4EF4EF48.9010503@FreeBSD.org> <20111224080617.GM80057@glebius.int.ru> <4EF589DF.9060606@FreeBSD.org> <20111224132924.GN80057@glebius.int.ru> <20111225001147.GA8035@glebius.int.ru> Date: Sat, 24 Dec 2011 17:55:03 -0800 Message-ID: From: Garrett Cooper To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Pyun Yong-Hyeon , Doug Barton , d@delphij.net, Eygene Ryabinkin , freebsd-rc@freebsd.org 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: Sun, 25 Dec 2011 01:55:13 -0000 2011/12/24 Gleb Smirnoff : > On Sat, Dec 24, 2011 at 11:02:17AM -0800, Garrett Cooper wrote: > G> 2011/12/24 Gleb Smirnoff : > G> > On Sat, Dec 24, 2011 at 12:14:23AM -0800, Doug Barton wrote: > G> > D> On 12/24/2011 00:06, Gleb Smirnoff wrote: > G> > D> > Do you suggest to adjust devd.conf in svn, or do you think that > G> > D> > zillions of server FreeBSD installations should modify the defa= ult > G> > D> > devd.conf to get rid of this spamming? > G> > D> > G> > D> There are zillions of FreeBSD servers with wlan interfaces? > G> > > G> > Current code spams console for any interfaces. > G> > G> =A0 =A0 Is that because of... > G> > G> console.info =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 /var/log/console.log > > Okay, it would spam /var/log/messages. Or maybe you'd suggedt to shut > it there, too? > > Any message about DHCP is absolutely irrelevent, and thus annoying on > a box running static IP configuration. Disabling logging of entire > syslog faclity is not a solution. Yeah. That's kind of what we're driving at in this discussion. I was just noting where the chattiness was possibly coming from. Thanks, -Garrett From owner-freebsd-rc@FreeBSD.ORG Sun Dec 25 07:20:12 2011 Return-Path: Delivered-To: freebsd-rc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 529EF1065672 for ; Sun, 25 Dec 2011 07:20:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 415F58FC08 for ; Sun, 25 Dec 2011 07:20:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pBP7KCR5015179 for ; Sun, 25 Dec 2011 07:20:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pBP7KCjL015178; Sun, 25 Dec 2011 07:20:12 GMT (envelope-from gnats) Date: Sun, 25 Dec 2011 07:20:12 GMT Message-Id: <201112250720.pBP7KCjL015178@freefall.freebsd.org> To: freebsd-rc@FreeBSD.org From: Maxim Ignatenko Cc: 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 Reply-To: Maxim Ignatenko 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: Sun, 25 Dec 2011 07:20:12 -0000 The following reply was made to PR conf/163508; it has been noted by GNATS. From: Maxim Ignatenko To: Doug Barton Cc: bug-followup@freebsd.org Subject: Re: conf/163508: [rc.subr] [patch] Add "enable" and "disable" commands to rc.subr Date: Sun, 25 Dec 2011 09:15:44 +0200 On 24 December 2011 22:59, Doug Barton wrote: > On 12/24/2011 04:20, Maxim Ignatenko wrote: >> The idea was to make enabling/disabling services less error-prone. > > How is adding foo_enable=1 to rc.conf error-prone? > Typo like fooo_enbale=1, or one missed '>' in echo foo_enable=1 > /etc/rc.conf From owner-freebsd-rc@FreeBSD.ORG Sun Dec 25 09:22:28 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 758DE1065670 for ; Sun, 25 Dec 2011 09:22:28 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 05DE38FC0A for ; Sun, 25 Dec 2011 09:22:27 +0000 (UTC) Received: by iadj38 with SMTP id j38so20424256iad.13 for ; Sun, 25 Dec 2011 01:22:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=B2EwLsqFTPBfBvDkr5OsoF86vo0TS4mxh1EU0ld08+Q=; b=THN1YDkZWUWPFO86dtugryXakEDsOypN9Y/X0LIW1AWbciqxj16qE9bD7per2d/Nbh 0iMFxBA36PgdTn96XJu8I5F0a+a5GHqNmKmm+ly6W5hhQalBG8pT2SOgzIVYtpLC+9jd 2CUQqOd2hIO63STcNkP1msxLZyiLCT4kTYHFA= Received: by 10.50.100.164 with SMTP id ez4mr1609091igb.12.1324804947289; Sun, 25 Dec 2011 01:22:27 -0800 (PST) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.231.30.70 with HTTP; Sun, 25 Dec 2011 01:21:56 -0800 (PST) In-Reply-To: <201112250720.pBP7KCjL015178@freefall.freebsd.org> References: <201112250720.pBP7KCjL015178@freefall.freebsd.org> From: Chris Rees Date: Sun, 25 Dec 2011 09:21:56 +0000 X-Google-Sender-Auth: chNtYIXzDm2JpBrJGB2Z9MaTK7Q Message-ID: To: Maxim Ignatenko Content-Type: text/plain; charset=ISO-8859-1 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: Sun, 25 Dec 2011 09:22:28 -0000 On 25 December 2011 07:20, Maxim Ignatenko wrote: > The following reply was made to PR conf/163508; it has been noted by GNAT= S. > > From: Maxim Ignatenko > To: Doug Barton > Cc: bug-followup@freebsd.org > Subject: Re: conf/163508: [rc.subr] [patch] Add "enable" and > =A0"disable" commands to rc.subr > Date: Sun, 25 Dec 2011 09:15:44 +0200 > > =A0On 24 December 2011 22:59, Doug Barton wrote: > =A0> On 12/24/2011 04:20, Maxim Ignatenko wrote: > =A0>> The idea was to make enabling/disabling services less error-prone. > =A0> > =A0> How is adding foo_enable=3D1 to rc.conf error-prone? > =A0> > > =A0Typo like fooo_enbale=3D1, or one missed '>' in echo foo_enable=3D1 > = /etc/rc.conf Let's think about this in a historical way... We (the BSDs) with our rcng have a massive advantage over the horrors of configuring a SysV init system; has anyone recently tried to change the 'runlevel' of a service on Debian without using rc-update? It involves putting numbered symlinks into each rcX.d We don't have this problem, it's as simple as adding a line to /etc/rc.conf(:?local)?. Yes, other systems have rc-update and cool magic like that, but our system is SO much simpler that these just aren't necessary. It's not a case of being error-prone; BSD: # echo 'foo_enable=3D"YES"' >>/etc/rc.conf SysV: # for runlevel in 1 2 3 4 5 ; do ln -s /etc/init.d/foo /etc/rc${runlevel}.d/S22foo ; done Chris From owner-freebsd-rc@FreeBSD.ORG Sun Dec 25 10:21:13 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 1E2D41065676; Sun, 25 Dec 2011 10:21:13 +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 9717C8FC18; Sun, 25 Dec 2011 10:21:12 +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:References:Message-ID:Subject:Cc:To:From:Date; bh=ZBmVmdTNKPTY+lNzlE2UJtaG3ZxiLi/Tk3iNgcIZqXE=; b=i7o2gNlSrpXwKsr/pBRUbWR5P3ktkgGO+cD/boE8x2ZV29oTiG3W0nlfYLZYl3E0N/GQaSlJp9RIGUcxzSE+5U348WB8EYOxz1ZfhLHlRGtDSK+KWT/WDfQc+4htqhXDLAYZ+Fo9lx0wXFl7QkNyddZs1RwcMrEcUX7FwNRxmePQilhjcUcJm2aV0DdImKfRErxGqzktuaTtemRiLDakD/jxKI4k6THNq9OUHQfZSA90hZYsS51Rz6u1t4Vt58PKdbIQlMUH2D7+uSq4pswr/wOspqHItJqCFNi3VXbXoKqgPizMGvLUcqVSafZZaxhBewDLhQWV0pCdih6URahY4Q==; Received: from shadow.codelabs.ru (ppp91-77-175-95.pppoe.mtu-net.ru [91.77.175.95]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1RelCX-0005CI-9e; Sun, 25 Dec 2011 13:21:10 +0300 Date: Sun, 25 Dec 2011 14:21:04 +0400 From: Eygene Ryabinkin To: Doug Barton Message-ID: References: <4EF6401E.3080902@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline In-Reply-To: <4EF6401E.3080902@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: Sun, 25 Dec 2011 10:21:13 -0000 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Sat, Dec 24, 2011 at 01:11:58PM -0800, Doug Barton wrote: > On 12/24/2011 03:21, Eygene Ryabinkin wrote: > > Please, explain your point here. (*) >=20 > I have, several times now, and I'm getting tired of explaining > it again. Excuse me, but I am failing to understand it. Your points were: a. rc_quiet is not intended to mask warnings [1]; it is _already_ masking errors, but only those that are caused by services that are disabled in rc.conf and, as explained by mtm@ [2], "quiet" was initially designed to do it; b. we should fix the caller, not the rc.d script [3]; I would do it if this was possible, but - there is not rc.subr machinery to do it without duplicating the checks inside dhclient; - I can't completely mask everything that goes from dhclient's stderr inside devd.conf, because it will mask "good" error messages as well. c. administrator's attention should be called upon when something unusual happens to the system [4]; that's true, but given that the devd blindly calls dhclient script, the error message will spam the logs and console. > We seem to have lost sight of what "asking for feedback" entails > around here. Namely that sometimes the feedback is, "That's a bad > idea, please don't do it." I've tried to say it politely, and I've > tried to explain the reasoning behind why what you're proposing is a > bad idea, but you don't agree with my reasoning. It's Ok that you > don't agree, I am already not asking for the feedback, I am just trying to understand your concerns about the current state of the "quiet" prefix and to bring the peace into the dhclient/devd problem. Though, yes, I don't agree, but I have technical arguments about the "quiet" stuff and desperately want to hear your _technical_ objections. My main beef here is the following one: we have two problems, a. "quiet" prefix is undocumented, so its usage isn't governed by any written rules; so different people have different opinions on how it must be used; b. current version of dhclient rc.d script in conjunction with the devd.conf causes a vast amount of noise in logs and console; for people who will be moving to 10.x from anything like <=3D 9.x this will introduce big POLA incident; that's not just my feelings, I already have 3 committers (Gleb, Xin and Pyun) who expressed their worries about the spam from devd/dhclient. I have solutions for both problems: - a) should be cured by documenting the desired usage of the "quiet" prefix; I had studied how it is used and traced its origins; just now it seems like it has the direct connection to the devd machinery (it was introduced to make it silent), but the only classes of messages it is intended to mask is the informative messages like "foo is starting" and errors from the services that being tried to be started but aren't enabled in the system; - b) will be fixed also by applying the newly-documented semantics of the "quiet" prefix to the dhclient case: DHCP is enabled by-interface basis in the rc.conf, so this isn't different from the case when one calls "service foo quietstart" without "foo_enabled" being set to "YES" in the rc.conf lair. > it's even Ok for you to naively assume that the reason I don't agree > is that I don't understand the issues/code/etc. as well as you do. I just wanted to point our that - your assertion about the code snippet I was citing was not 100% correct and given my background (I am physicist by education and my main area is theory, so I have strong mathematical background as well) I am trying to give the assertions that are close to being 100% correct; I was not trying to say that you don't understand the issues _as well as I do_, in fact, I am on the opposite side: I am trying to understand you POV, because you seem to work with the rc.d stuff a way longer than I am and I could understand the issues with this subsystem a way worse than you; but I won't blindly buy any arguments given even by the God himself, I need the facts I can draw conclusions from; - you were talking about the case where rc.d script will proceed, but I was studying the code path where it will fail and my intention was to clarify the usage of the "quiet" prefix here. My verbose study of the snippet was also partly the reality check in respect to my understanding of it: we're all humans and can miss some important things even from the simple code. > But that doesn't change the fact that what you're proposing is a bad > idea. I think that it is best way to fix the issue given the current state of the devd/rc.subr relations and established practices of devd logging, but I am a bit biased here ;) > For the record: It's more important for users to see error messages > for interfaces that *should* be configured, but don't succeed; than > it is to hide occasional spam for interfaces where configuration is > attempted spuriously. Are you talking about the cases where - administrator invoked "service dhclient start" and where he will see the full error message with my patch, - or the case where he does (the currently undocumented) 'quietstart' and won't see the error, - or the case where he relies on the devd to plug the interface, but won't see the error? I think that only the latter case is relevant, but given the - current rc.subr behaviour in respect to "quiet" prefix where administrator won't see _any_ errors that are caused by the disabled services; - current reality is that the majority of error messages about non-enabled DHCP on the interface that come from devd will be pure spam, it is better to sync with the current behaviour and to shut this message too. Moreover, the current implementation doesn't go out of sync with your maxima cited above, "It's more important for users to see error messages for interfaces that *should* be configured, but don't succeed": the problem is in determining what interfaces should be configured. My measure for "should" in the dhclient case is the presence of the "dhcp" keyword in the interface configuration: when it is here, the patched dhclient will give away every error that it will face during interface's configure phase. What's the problem here? > If *you* don't want to see that spam then *you* have it in your > power, through various configuration knobs, to make it stop. > If you don't care to do that, that's your choice as well. No, I don't have the power to stop is via the configuration without going into the details of device/vendor IDs (and even would I go to that details, I will have only binary on/off state for _all_ errors; "details" allow me only to choose the interfaces, not the error classes): that's the main reason. We have no fine-grained knobs (*) for the devd/rc.subr to say "don't give me that error, but give all other ones". All we can say is "give me every error" or "give me no errors" for any particular entry. (*): err, we have the "quiet" knob that I am trying to document and use, but you're telling me that it is a bad idea and I am trying to understand why, but currently failing to. > At this point we've already expended way more energy on this topic > than it was ever worth. Doug, let's speak technically: if you would answer to my straight and technical questions raised in [5], I won't be forced to write this rather long letter, people won't be forced to read it and, I am sure, we will be close to the consensus about this problem that we currently are. Some part of the system has problems, partly due to my commit, partly by the undocumented behaviour. I have solution that suits all people who participated in this thread, but you. I will be trying to understand what's wrong with the solution until I will understand it or you will start to ignore my whinings. But since you had the liberty to express your opinion on the problem, I think that it will be fair to answer to my technical questions, at least. And, please, don't mark this problem as "it is not worth the time already spent": some power-users of -CURRENT feel that it is POLA breakage and general annoyance, so this might be another small reason that, in conjunction with the other ones, will make regular administrators to say "well, FreeBSD isn't a way to go, let's go $THEOTHEROS". References: [1] http://lists.freebsd.org/pipermail/freebsd-rc/2011-November/002484.html [2] http://lists.freebsd.org/pipermail/freebsd-rc/2011-November/002500.html [3] http://lists.freebsd.org/pipermail/freebsd-rc/2011-November/002489.html [4] http://lists.freebsd.org/pipermail/freebsd-rc/2011-November/002473.html [5] http://lists.freebsd.org/pipermail/freebsd-rc/2011-December/002542.html --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iF4EAREIAAYFAk72+RAACgkQFq+eroFS7Pt6rAD+NbB8TeQbDZOh3lX40ffoqnNM zBiBfRWYf/cTPMYvjwUA/AxriJQ9bHoJI5QABf1pRKIY79e23fVodsesvoEr6T3E =+fk5 -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL-- From owner-freebsd-rc@FreeBSD.ORG Mon Dec 26 05:56:56 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 7CD58106564A; Mon, 26 Dec 2011 05:56:56 +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 F3CB614DB07; Mon, 26 Dec 2011 05:56:55 +0000 (UTC) Message-ID: <4EF80CA7.3070303@FreeBSD.org> Date: Sun, 25 Dec 2011 21:56:55 -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: Jilles Tjoelker References: <4EF6401E.3080902@FreeBSD.org> <20111224215649.GA12789@stack.nl> In-Reply-To: <20111224215649.GA12789@stack.nl> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Pyun Yong-Hyeon , d@delphij.net, Garrett Cooper , Eygene Ryabinkin , Gleb Smirnoff , freebsd-rc@freebsd.org 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: Mon, 26 Dec 2011 05:56:56 -0000 On 12/24/2011 13:56, Jilles Tjoelker wrote: > On Sat, Dec 24, 2011 at 01:11:58PM -0800, Doug Barton wrote: >> On 12/24/2011 03:21, Eygene Ryabinkin wrote: >>> Please, explain your point here. (*) > >> I have, several times now, and I'm getting tired of explaining it again. >> We seem to have lost sight of what "asking for feedback" entails around >> here. Namely that sometimes the feedback is, "That's a bad idea, please >> don't do it." I've tried to say it politely, and I've tried to explain >> the reasoning behind why what you're proposing is a bad idea, but you >> don't agree with my reasoning. It's Ok that you don't agree, it's even >> Ok for you to naively assume that the reason I don't agree is that I >> don't understand the issues/code/etc. as well as you do. But that >> doesn't change the fact that what you're proposing is a bad idea. > >> For the record: It's more important for users to see error messages for >> interfaces that *should* be configured, but don't succeed; than it is to >> hide occasional spam for interfaces where configuration is attempted >> spuriously. > > And rea@'s patch does this: > service dhclient start IF > generates error messages if IF is not enabled for DHCP in rc.conf, while > service dhclient quietstart IF > does not. > > This works the same way as service food start/quietstart when food is > not enabled in rc.conf. > > Therefore I do not see what is wrong with rea@'s patch. That's not the interesting case. The interesting case is the interface *is* configured with DHCP, but no error message is generated when it fails because they've been hidden. >> If *you* don't want to see that spam then *you* have it in your power, >> through various configuration knobs, to make it stop. If you don't care >> to do that, that's your choice as well. At this point we've already >> expended way more energy on this topic than it was ever worth. > > In general, I think the defaults should be set up like a user would want > them. This is because people want to edit the configuration files as > little as possible and also as few of them as possible, so upgrading is > as easy as possible. > > On a server, /etc/devd.conf rarely needs any changes, so for the purpose > of this issue assume that it will not be modified and there will be > error messages needlessly confusing people. That's the bit that's confusing to me. I've administered hundreds of FreeBSD systems, servers and desktops, with and without DHCP, and I don't remember ever seeing these messages. Perhaps someone can show the configuration combination that will create them? If so, I'll be glad to give the patch another look to confirm that my concerns about false negatives are being addressed. Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-rc@FreeBSD.ORG Mon Dec 26 06:12:46 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 6F35A106566C for ; Mon, 26 Dec 2011 06:12:46 +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 E51C3177915; Mon, 26 Dec 2011 06:12:45 +0000 (UTC) Message-ID: <4EF8105D.3030907@FreeBSD.org> Date: Sun, 25 Dec 2011 22:12:45 -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: Warner Losh References: <201112241230.pBOCUF3h064098@freefall.freebsd.org> <4EF64915.4030006@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 06:12:46 -0000 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. >> 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. > > We should encourage others solving the problem completely. IMO that's pie in the sky. >> Which returns me to my original point, how hard is it to edit >> rc.conf anyway? > > Scripts would greatly benefit from having a robust way to do things > without humans in the loop. I'm not convinced that's a feature, but I'm willing to be persuaded. > Some folks also would find it easier. 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. > Basically, we shouldn't get in the way here by telling people it > can't be done. Then we get nothing. > > 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. 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. My bottom line is that if you (Warner) or some group of committers want to commit to: 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) 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. Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ 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= From owner-freebsd-rc@FreeBSD.ORG Mon Dec 26 07:06:09 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 411EB1065672 for ; Mon, 26 Dec 2011 07:06:09 +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 6E16315118B; Mon, 26 Dec 2011 07:06:08 +0000 (UTC) Message-ID: <4EF81CE0.9080802@FreeBSD.org> Date: Sun, 25 Dec 2011 23:06:08 -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: Garrett Cooper References: <201112241230.pBOCUF3h064098@freefall.freebsd.org> <4EF64915.4030006@FreeBSD.org> <4EF8105D.3030907@FreeBSD.org> <286B56F0-CD3B-4B1C-A5DE-45BC2CAFEB89@gmail.com> In-Reply-To: <286B56F0-CD3B-4B1C-A5DE-45BC2CAFEB89@gmail.com> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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:06:09 -0000 On 12/25/2011 23:00, Garrett Cooper wrote: > On Dec 25, 2011, at 10:12 PM, 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 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. >> >>>> 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. >>> >>> We should encourage others solving the problem completely. >> >> IMO that's pie in the sky. >> >>>> Which returns me to my original point, how hard is it to edit >>>> rc.conf anyway? >>> >>> Scripts would greatly benefit from having a robust way to do things >>> without humans in the loop. >> >> I'm not convinced that's a feature, but I'm willing to be persuaded. >> >>> Some folks also would find it easier. >> >> 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. >> >>> Basically, we shouldn't get in the way here by telling people it >>> can't be done. Then we get nothing. >>> >>> 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. >> >> 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. >> >> My bottom line is that if you (Warner) or some group of committers want >> to commit to: >> >> 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) >> >> 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 constraints 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 and won't be handled by the script/infrastructure. > Once the caveats are documented and understood, we should have the bases covered, s.t. this will handle the majority of the valid cases that the patch is attempting to address. I think that it sounds great to say "do this, and no more," but that ultimately trying to limit the scope in this way is going to cause way more problems than it solves. But, now I'm repeating myself. If you (Garrett) are willing to commit to both the short and long term support of users and code affected by this change (as described in my points 2. and 3. above) then I wish you all the best. Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-rc@FreeBSD.ORG Mon Dec 26 08:17:09 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 E61A9106564A; Mon, 26 Dec 2011 08:17:08 +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 7314B8FC08; Mon, 26 Dec 2011 08:17:08 +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:References:Message-ID:Subject:Cc:To:From:Date; bh=e+ZmttWICJ/XwmZICAeouhpCGbUqb5QZIRNnHQUH1fI=; b=tR44q/ArBWlA7J/7JyPFmfBGWan4SUjBs2a8cHjT9HNECYm67+AGQbhi+HC4g4eGSBE1S6g+ChogbCDOkXt8qMubIy+a4EuYuNa3y3lAqTn8rPYAsCK9rnqSiWwANxwcN6pXJrCdC4YB9pV00BBOutsMAPeyE9lVHJwI2ZJiE1MffTVB6iEafp0Cq9Tuq4FL/xIuswMFYep0QJG/cX1ekUg1yzZKF4j2a8HH0xglPy7kamc4mf6WzTLbwql2eMflJJhZmD0ahn5ua8eABnSjvqh7vCpJputO+umx0/GOq4PdGrA56e3MrZsddC4iz8tLcWw2ProHfOYtsvFhQJZy2g==; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1Rf5k0-000Bwj-4H; Mon, 26 Dec 2011 11:17:04 +0300 Date: Mon, 26 Dec 2011 12:17:00 +0400 From: Eygene Ryabinkin To: Doug Barton Message-ID: References: <4EF6401E.3080902@FreeBSD.org> <20111224215649.GA12789@stack.nl> <4EF80CA7.3070303@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DMLl6fZPX8o7hGmc" Content-Disposition: inline In-Reply-To: <4EF80CA7.3070303@FreeBSD.org> Sender: rea@codelabs.ru Cc: Pyun Yong-Hyeon , d@delphij.net, Garrett Cooper , Gleb Smirnoff , freebsd-rc@freebsd.org 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: Mon, 26 Dec 2011 08:17:09 -0000 --DMLl6fZPX8o7hGmc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Sun, Dec 25, 2011 at 09:56:55PM -0800, Doug Barton wrote: > On 12/24/2011 13:56, Jilles Tjoelker wrote: > > And rea@'s patch does this: > > service dhclient start IF > > generates error messages if IF is not enabled for DHCP in rc.conf, while > > service dhclient quietstart IF > > does not. > >=20 > > This works the same way as service food start/quietstart when food is > > not enabled in rc.conf. > >=20 > > Therefore I do not see what is wrong with rea@'s patch. >=20 > That's not the interesting case. The interesting case is the interface > *is* configured with DHCP, but no error message is generated when it > fails because they've been hidden. The error message "'$ifn' is not a DHCP-enabled interface" is not generated when $ifn is DHCP-enabled interface, {{{ dhclient_pre_check() { if [ -z "${rc_force}" ] && ! dhcpif $ifn; then local msg msg=3D"'$ifn' is not a DHCP-enabled interface" if [ -z "${rc_quiet}" ]; then err 1 "$msg" else debug "$msg" exit 1 fi fi } }}} '! dhcpif $ifn' guarantees it. And all other errors aren't masked by my patch, so everything is fine here. The only way to miss the diagnostic message is to rely that devd will configure your interface automagically while one forget to enable DHCP on the interface he expect to automagificy. That's pity, but the lone 'service dhclient start $if' or 'service netif start $if' will reveal the truth. > That's the bit that's confusing to me. I've administered hundreds of > FreeBSD systems, servers and desktops, with and without DHCP, and I > don't remember ever seeing these messages. They will show up only for people who are running HEAD with /usr/src r226879 or later: the changes weren't MFCed into any RELENG branch yet. > Perhaps someone can show the configuration combination that will > create them? My way to reproduce it with Ethernet-only configuration is just to unplug and plug back the cord to the switch to generate the linkup event that will push devd. You will need dhclient from r226879 and not the patched one (with dhclient_pre_check cited above), because it won't generate noise -- it uses 'debug' for the devd invocation. The same thing should be seen for the WiFi interfaces that aren't DHCP-enabled. Left my FreeBSD-enabled notebook at home, so can't test is just now. > If so, I'll be glad to give the patch another look to confirm that > my concerns about false negatives are being addressed. Will be very good. Thanks. --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --DMLl6fZPX8o7hGmc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iF4EAREIAAYFAk74LXwACgkQFq+eroFS7PscJgD/RvU2meLFhSVfzjrQxD2dlsX8 kckdFxnsoTgwQgJ+BP4A/2+sfW1cxEBMORVVlfewFa2C3c8e9+YdmPdtYuJo2xMG =N27O -----END PGP SIGNATURE----- --DMLl6fZPX8o7hGmc-- From owner-freebsd-rc@FreeBSD.ORG Mon Dec 26 08:20:12 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 70C561065673; Mon, 26 Dec 2011 08:20:12 +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 16BB6152A03; Mon, 26 Dec 2011 08:20:12 +0000 (UTC) Message-ID: <4EF82E3B.6040601@FreeBSD.org> Date: Mon, 26 Dec 2011 00:20:11 -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: <4EF6401E.3080902@FreeBSD.org> <20111224215649.GA12789@stack.nl> <4EF80CA7.3070303@FreeBSD.org> 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 , d@delphij.net, Garrett Cooper , Gleb Smirnoff , freebsd-rc@freebsd.org 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: Mon, 26 Dec 2011 08:20:12 -0000 On 12/26/2011 00:17, Eygene Ryabinkin wrote: > The error message "'$ifn' is not a DHCP-enabled interface" is not generated > when $ifn is DHCP-enabled interface, That's precisely the failure I'm concerned about. Also, can you please respond to the bit where I asked for configuration examples that produce the error? -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-rc@FreeBSD.ORG Mon Dec 26 08:39:35 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 915751065675; Mon, 26 Dec 2011 08:39:35 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 10B498FC13; Mon, 26 Dec 2011 08:39:34 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pBQ8dXgV018084; Mon, 26 Dec 2011 12:39:33 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pBQ8dXJb018083; Mon, 26 Dec 2011 12:39:33 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 26 Dec 2011 12:39:33 +0400 From: Gleb Smirnoff To: Doug Barton Message-ID: <20111226083933.GB8035@glebius.int.ru> References: <4EF6401E.3080902@FreeBSD.org> <20111224215649.GA12789@stack.nl> <4EF80CA7.3070303@FreeBSD.org> <4EF82E3B.6040601@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4EF82E3B.6040601@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Pyun Yong-Hyeon , d@delphij.net, Garrett Cooper , Eygene Ryabinkin , freebsd-rc@FreeBSD.org 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: Mon, 26 Dec 2011 08:39:35 -0000 On Mon, Dec 26, 2011 at 12:20:11AM -0800, Doug Barton wrote: D> On 12/26/2011 00:17, Eygene Ryabinkin wrote: D> > The error message "'$ifn' is not a DHCP-enabled interface" is not generated D> > when $ifn is DHCP-enabled interface, D> D> That's precisely the failure I'm concerned about. D> D> Also, can you please respond to the bit where I asked for configuration D> examples that produce the error? Prerequisites: 1) HEAD 2) Any non-DHCP configuration. -- Totus tuus, Glebius. From owner-freebsd-rc@FreeBSD.ORG Mon Dec 26 08:40:43 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 9C776106566C; Mon, 26 Dec 2011 08:40:43 +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 315F78FC12; Mon, 26 Dec 2011 08:40:43 +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:References:Message-ID:Subject:Cc:To:From:Date; bh=wDsNATbZr7wxY1lDchuMgwAMExEeFBAvIWhYRdCgAz8=; b=k2ltxXKVxhzYahdE2JF7HAW1jb2zegBbJi/sko0oHTgRpKowrEuFbhekr9PhAC1JmnmiNqPJSkWQv5+DzB7yFtddZkoeg5dESVrwtHWfbH+Qv1r0HM1bhu1LInKYdZ+2JmG+UIYXWpExbBm+QF/5eFj1rEU9xCMhBI6wu7D4wpCFq3LfULmPD/Ncj0QJXlguAWYm8g6tbxz8IoOH0DigG8tSlDrrRYoxzyhx5n7hP6Hxzj4oECUXT+M0l0p3U4xLbx9KcmHIujrMeg4J3gKEoFoY6VsPIqtbFkTFprjU/uxRuusI+toUJ7F8ymCtYbN8l+BzbUfBrApwk0XuYaM9BQ==; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1Rf66r-000DxC-Sa; Mon, 26 Dec 2011 11:40:42 +0300 Date: Mon, 26 Dec 2011 12:40:38 +0400 From: Eygene Ryabinkin To: Doug Barton Message-ID: References: <4EF6401E.3080902@FreeBSD.org> <20111224215649.GA12789@stack.nl> <4EF80CA7.3070303@FreeBSD.org> <4EF82E3B.6040601@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BZziOT8Kz25R/m/E" Content-Disposition: inline In-Reply-To: <4EF82E3B.6040601@FreeBSD.org> Sender: rea@codelabs.ru Cc: Pyun Yong-Hyeon , d@delphij.net, Garrett Cooper , Gleb Smirnoff , freebsd-rc@freebsd.org 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: Mon, 26 Dec 2011 08:40:43 -0000 --BZziOT8Kz25R/m/E Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Mon, Dec 26, 2011 at 12:20:11AM -0800, Doug Barton wrote: > On 12/26/2011 00:17, Eygene Ryabinkin wrote: > > The error message "'$ifn' is not a DHCP-enabled interface" is not > > generated when $ifn is DHCP-enabled interface, >=20 > That's precisely the failure I'm concerned about. Doug, how that can be a failure? If dhclient will say "foo0 is not a DHCP-enabled interface" when foo0 has DHCP activated, then it will be a failure. But what you're saying now looks funny: do you really insist that I should say "it is not a DHCP-enabled interface" for the interface that is DHCP-enabled? If dhclient would deny to say "DHCP configuration of '$ifn' failed" in the case of quietstart, then it will be the failure. But my version says the other thing "It is pointless to try DHCP on this interface, because it is not DHCP-enabled". May be we should change "it is not a DHCP-enabled" to "DHCP is not enabled on this interface", but what you're saying contradicts either with logics or my understanding of what "'$ifn' is not a DHCP-enabled interface" means to a native speakers of English language. My dusty magic ball tells me that you may be talking about the other paragraph from my last mail, {{{ The only way to miss the diagnostic message is to rely that devd will configure your interface automagically while one forget to enable DHCP on the interface he expect to automagificy. That's pity, but the lone 'service dhclient start $if' or 'service netif start $if' will reveal the truth. }}} but then you're quoting the wrong part of my message. Otherwise, please, clarify, what the failure is and how it can be repeated. > Also, can you please respond to the bit where I asked for > configuration examples that produce the error? OK, here we go: {{{ ifconfig_msk0=3D"inet XXX.XXX.XXX.XXX/24 media autoselect" }}} but the bare {{{ ifconfig_msk0=3D"up" }}} or 'ifconfig msk0 up' from the command-line will be sufficient: we just need to generate the IFUP event for devd and interface should be in the "up" state for that. Boot up the system or have the booted one with at interface in the "up" state, unplug the Ethernet cord once it is fully booted and plug it back (to simulate link loss) and watch your /var/log/messages. If you won't be able to simulate this using what I just said, I will need the contents of your - /etc/rc.conf (only interface configuration and things related to devd and syslog) - /etc/devd.conf - /etc/syslog.conf - /etc/rc.d/dhclient --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --BZziOT8Kz25R/m/E Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iF4EAREIAAYFAk74MwYACgkQFq+eroFS7PvCwgD/d0XCgbUTsfAIWQhdr7Tz6o1D +swvHyeItwX4w+eDd5sA/RFUy6g085M0Jhs/dJw/y7t8TT37Nwqzg87EAQHzVqm7 =m5uR -----END PGP SIGNATURE----- --BZziOT8Kz25R/m/E-- From owner-freebsd-rc@FreeBSD.ORG Mon Dec 26 08:43:36 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 66C621065673; Mon, 26 Dec 2011 08:43:36 +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 E3BA115051D; Mon, 26 Dec 2011 08:43:35 +0000 (UTC) Message-ID: <4EF833B7.9040704@FreeBSD.org> Date: Mon, 26 Dec 2011 00:43:35 -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: <4EF6401E.3080902@FreeBSD.org> <20111224215649.GA12789@stack.nl> <4EF80CA7.3070303@FreeBSD.org> <4EF82E3B.6040601@FreeBSD.org> 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 , d@delphij.net, Garrett Cooper , Gleb Smirnoff , freebsd-rc@freebsd.org 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: Mon, 26 Dec 2011 08:43:36 -0000 On 12/26/2011 00:40, Eygene Ryabinkin wrote: > Doug, how that can be a failure? How does anything fail? Isn't that why you call it a "failure" instead of a "success?" But if Gleb is right and the problem is new to HEAD, when did it change, and why? I get that you're motivated by the best of intentions. My concern remains that we're trying fix the symptom rather than the root cause. -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-rc@FreeBSD.ORG Mon Dec 26 09:01:02 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 5C4C4106566B; Mon, 26 Dec 2011 09:01:02 +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 019198FC0C; Mon, 26 Dec 2011 09:01:01 +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:References:Message-ID:Subject:Cc:To:From:Date; bh=HUbM8GCQdgXE7ezdTLCX0nt4AyDMvuSAo3BhcEtDEH0=; b=s4CtLJc4EjZM1hMpZjfvt29n7lcD8p6WIRhzbeuPllTHE8DLEHyjjA+PKytR+hK+T0hSlCcp87fwVUk5RhhVtP95xk1crHP4X7nyj2HO5K3CxEGGEj9hEBaUNEXlLI+ToNq/jL0dJFFwAQaNgSn4o2WSTZUvJLMCUtVaJBkrADppGKmIQMzjV/ZTLA+j5eL5oQgPnWH/vvu4qsNmCpgU7j6BCP4Jly8eTH1842w38zZ4U8QjfYqHmm4G3xhvT3b630PqawyPaebD4LdDnc/j5wkMGEM0bSUVzXAwJkmM80AHa/Sm/yGPAta133tY86gZ4Uh8zHcDrR100iqqF9/Jvw==; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1Rf6QW-000Fcl-4k; Mon, 26 Dec 2011 12:01:00 +0300 Date: Mon, 26 Dec 2011 13:00:57 +0400 From: Eygene Ryabinkin To: Doug Barton Message-ID: References: <4EF6401E.3080902@FreeBSD.org> <20111224215649.GA12789@stack.nl> <4EF80CA7.3070303@FreeBSD.org> <4EF82E3B.6040601@FreeBSD.org> <4EF833B7.9040704@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="iskw6J4cuOvZ6IVF" Content-Disposition: inline In-Reply-To: <4EF833B7.9040704@FreeBSD.org> Sender: rea@codelabs.ru Cc: Pyun Yong-Hyeon , d@delphij.net, Garrett Cooper , Gleb Smirnoff , freebsd-rc@freebsd.org 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: Mon, 26 Dec 2011 09:01:02 -0000 --iskw6J4cuOvZ6IVF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Mon, Dec 26, 2011 at 12:43:35AM -0800, Doug Barton wrote: > On 12/26/2011 00:40, Eygene Ryabinkin wrote: > > Doug, how that can be a failure? >=20 > How does anything fail? Isn't that why you call it a "failure" instead > of a "success?" Doug, I am sorry, but let's drop the theoretical discussions about how things are failing -- this is out of scope. Back to the message you're replying to: {{{ Mon, Dec 26, 2011 at 12:20:11AM -0800, Doug Barton wrote: > On 12/26/2011 00:17, Eygene Ryabinkin wrote: > > The error message "'$ifn' is not a DHCP-enabled interface" is not > > generated when $ifn is DHCP-enabled interface, > > That's precisely the failure I'm concerned about. }}} I am translating the whole dialog to the following one: - rea: error message " am not a cat" isn't generated when the is a cat. - dougb: that's the failure I am concerned about. - rea: how this can be a failure to refuse to say "something isn't a cat" when it _is_ a cat? - dougb: how does anything fail? Isn't that why you call it a "failure" instead of a "success"? Please, tell specifically, what is the failure you're concerned about and how it will affect people who use FreeBSD? > But if Gleb is right and the problem is new to HEAD, when did it change, > and why? Doug, had you read the initial message of the thread? It is on http://lists.freebsd.org/pipermail/freebsd-rc/2011-November/002472.html To ease the life, I can answer that - the problem was introduced in r226879 - by me - I was fixing my previous commit that generated r226464 - the purpose of r226464 was to fix the rc_force check in dhclient script > I get that you're motivated by the best of intentions. My concern > remains that we're trying fix the symptom rather than the root cause. Let me ask the simple question: what do you think is the root cause you're talking about? --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --iskw6J4cuOvZ6IVF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iF4EAREIAAYFAk74N8kACgkQFq+eroFS7PunLwD/eerXWVdbKl7ROXVteygLSqY1 DqdUC8ZVY7XzDmPDE3AA/1tf13KudJ4l2S/bxCMl5apBHAih45q9nuZspL1QBnxD =PQI9 -----END PGP SIGNATURE----- --iskw6J4cuOvZ6IVF-- From owner-freebsd-rc@FreeBSD.ORG Mon Dec 26 09:02:38 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 D8331106564A; Mon, 26 Dec 2011 09:02:38 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 58CF08FC0C; Mon, 26 Dec 2011 09:02:38 +0000 (UTC) Received: by ggnp1 with SMTP id p1so10826280ggn.13 for ; Mon, 26 Dec 2011 01:02:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=VIfOKcGnXxXzSCNFVxnlTJOj2ykYUF6fdiVTFAjL3Uw=; b=DgETyr6iIu1r3bLqcR/4iRFL2XBaN5G9qZlZZ4Yq/Dq4IRXfucwVoKBjRQabuJtTr7 QHloo17rHIkr3VSJQTn4pemq/VlyKQRGD3sCQ6TGXl/OgkJx+qCXCNA3Z/MGz8yaXG4k DdqIacq1s0YehM5Bhb2Drj0oFzksz0D9o8ZJs= Received: by 10.101.24.16 with SMTP id b16mr9762976anj.36.1324890157515; Mon, 26 Dec 2011 01:02:37 -0800 (PST) Received: from [192.168.2.5] (dpc691944246.direcpc.com. [69.19.44.246]) by mx.google.com with ESMTPS id c10sm33939688yhj.2.2011.12.26.01.02.21 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Dec 2011 01:02:36 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Garrett Cooper In-Reply-To: <4EF833B7.9040704@FreeBSD.org> Date: Mon, 26 Dec 2011 01:02:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0A59E5CD-3598-41B0-A707-6C5185E80043@gmail.com> References: <4EF6401E.3080902@FreeBSD.org> <20111224215649.GA12789@stack.nl> <4EF80CA7.3070303@FreeBSD.org> <4EF82E3B.6040601@FreeBSD.org> <4EF833B7.9040704@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1251.1) Cc: Pyun Yong-Hyeon , d@delphij.net, Eygene Ryabinkin , Gleb Smirnoff , freebsd-rc@freebsd.org 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: Mon, 26 Dec 2011 09:02:38 -0000 On Dec 26, 2011, at 12:43 AM, Doug Barton wrote: > On 12/26/2011 00:40, Eygene Ryabinkin wrote: >> Doug, how that can be a failure? >=20 > How does anything fail? Isn't that why you call it a "failure" instead > of a "success?" >=20 > But if Gleb is right and the problem is new to HEAD, when did it = change, > and why? 226879 rea if [ -z "${rc_force}" ] && ! dhcpif $ifn; then 226879 rea err 1 "'$ifn' is not a DHCP-enabled = interface" 226879 rea fi $ svn log -r 226879 ------------------------------------------------------------------------ r226879 | rea | 2011-10-27 23:03:38 -0700 (Thu, 27 Oct 2011) | 10 lines Fix handling of rc_force in /etc/rc.d/dhclient Variable 'rc_force' is accessible only at the time of rc_run_command, so it can't be examined from the script's main code. Spotted by: hrs Reviewed by: hrs, des Approved by: des MFC after: 2 weeks ------------------------------------------------------------------------ It simply didn't exist before this change; before it was just a 'return = 1', which is illegal outside of functions, amongst other things. So I vote to just remove the message (convert the err 1 to a exit 1) and = MFC back to 9.0=85 please, because this change is present there now. We can argue about the semantics of rc_quiet later. Tons of people just = care about the fact that the message is showing up and don't really care = about the semantics. Thanks, -Garrett= From owner-freebsd-rc@FreeBSD.ORG Mon Dec 26 09:11:54 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 10F281065670; Mon, 26 Dec 2011 09:11:54 +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 7937E14F59F; Mon, 26 Dec 2011 09:11:53 +0000 (UTC) Message-ID: <4EF83A59.8080008@FreeBSD.org> Date: Mon, 26 Dec 2011 01:11:53 -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: Garrett Cooper References: <4EF6401E.3080902@FreeBSD.org> <20111224215649.GA12789@stack.nl> <4EF80CA7.3070303@FreeBSD.org> <4EF82E3B.6040601@FreeBSD.org> <4EF833B7.9040704@FreeBSD.org> <0A59E5CD-3598-41B0-A707-6C5185E80043@gmail.com> In-Reply-To: <0A59E5CD-3598-41B0-A707-6C5185E80043@gmail.com> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Pyun Yong-Hyeon , d@delphij.net, Eygene Ryabinkin , Gleb Smirnoff , freebsd-rc@freebsd.org 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: Mon, 26 Dec 2011 09:11:54 -0000 On 12/26/2011 01:02, Garrett Cooper wrote: > On Dec 26, 2011, at 12:43 AM, Doug Barton wrote: > >> On 12/26/2011 00:40, Eygene Ryabinkin wrote: >>> Doug, how that can be a failure? >> >> How does anything fail? Isn't that why you call it a "failure" >> instead of a "success?" >> >> But if Gleb is right and the problem is new to HEAD, when did it >> change, and why? > > 226879 rea if [ -z "${rc_force}" ] && ! dhcpif $ifn; > then 226879 rea err 1 "'$ifn' is not a > DHCP-enabled interface" 226879 rea fi > > $ svn log -r 226879 > ------------------------------------------------------------------------ > > r226879 | rea | 2011-10-27 23:03:38 -0700 (Thu, 27 Oct 2011) | 10 lines > > Fix handling of rc_force in /etc/rc.d/dhclient > > Variable 'rc_force' is accessible only at the time of > rc_run_command, so it can't be examined from the script's main code. > > Spotted by: hrs Reviewed by: hrs, des Approved by: des MFC after: 2 > weeks > ------------------------------------------------------------------------ > > It simply didn't exist before this change; before it was just a > 'return 1', which is illegal outside of functions, amongst other > things. Ok, so I think here is some of the source of the confusion: "The syntax of the return command is return [exitstatus] It terminates the current executional scope, returning from the previous nested function, sourced script, or shell instance, in that order. The return command is implemented as a special built-in command." It's actually used often'ish in rc.d where exit cannot be. > So I vote to just remove the message (convert the err 1 to a exit 1) I haven't dug into it yet, but if it was a return previously it almost certainly should not be an exit now. I'll dig into the original change more tomorrow, now that it's clear what we're actually dealing with. Thanks to both of you for helping to make it clear. Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-rc@FreeBSD.ORG Mon Dec 26 09:19:11 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 78B291065676; Mon, 26 Dec 2011 09:19:11 +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 1E2458FC1A; Mon, 26 Dec 2011 09:19:10 +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:References:Message-ID:Subject:Cc:To:From:Date; bh=mASSW/909E90INvXY9zjHjFqA176IcctgT1qlbNQKV4=; b=q6vVp5reWn0wCPtETFFQh9fAKlKChKuXA36C9ax3m9On2kZxojQRx9+GbcmLMWC9Sh9Gr1uAesowExVR/Itu3v/O/nbQ2blK7IYrHCJlQyb3QY2SMhfFvBLw7nTv3zxD7HRiBHathTQFb76CTrXGPD6aJEzz2PiAXhNykVJNVbCvy2zbbA48JHbwgcaNHDzxzT6zKF2tajjRQKfECJ99FXuB12ZQOiuZarONTkvQngNoYQ6aZajlpAE/g1MrrvD78/LrhLGVvFmNdM41grCP00FAu5mc1gR5izm9j+uTxvZDWA39exzd/fka6vy1XY8S6uaDK8Wvs2eN9uTInu1MQg==; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1Rf6i5-000H6C-Jw; Mon, 26 Dec 2011 12:19:09 +0300 Date: Mon, 26 Dec 2011 13:19:06 +0400 From: Eygene Ryabinkin To: Garrett Cooper Message-ID: References: <4EF6401E.3080902@FreeBSD.org> <20111224215649.GA12789@stack.nl> <4EF80CA7.3070303@FreeBSD.org> <4EF82E3B.6040601@FreeBSD.org> <4EF833B7.9040704@FreeBSD.org> <0A59E5CD-3598-41B0-A707-6C5185E80043@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xbjSOCWVZ1q9zj4g" Content-Disposition: inline In-Reply-To: <0A59E5CD-3598-41B0-A707-6C5185E80043@gmail.com> Sender: rea@codelabs.ru Cc: Pyun Yong-Hyeon , Doug Barton , d@delphij.net, Gleb Smirnoff , freebsd-rc@freebsd.org 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: Mon, 26 Dec 2011 09:19:11 -0000 --xbjSOCWVZ1q9zj4g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Garret, good day. Mon, Dec 26, 2011 at 01:02:06AM -0800, Garrett Cooper wrote: > So I vote to just remove the message (convert the err 1 to a exit 1) > and MFC back to 9.0? please, because this change is present there > now. No, it isn't: http://svn.freebsd.org/base/stable/9/etc/rc.d/dhclient http://svn.freebsd.org/base/releng/9.0/etc/rc.d/dhclient Even the des@ change that my commits were trying to fix http://svnweb.freebsd.org/base/head/etc/rc.d/dhclient?r1=3D178233&r2=3D22= 6345 isn't MFCed to any RELENG branch. > We can argue about the semantics of rc_quiet later. Since this stuff is HEAD-only, then, in my opinion, there is no need to revert the stuff: the policy of HEAD that it is a proving ground for the changes in the FreeBSD code, so it can have some rough points =66rom time to time. > Tons of people just care about the fact that the message is showing > up and don't really care about the semantics. For some definition of "tons", yes. If this change would be MFCed to 9.x, then "tons" will really be a large number. But since this is HEAD-only problem and, I think, we're getting closer to its solution with each second, we can aim at caring about the semantics and about the proper fix for it. Though, I can not fully understand the HEAD best practices and this stuff should/must be really reverted. If so, someone should point me to the right direction. Thanks. --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --xbjSOCWVZ1q9zj4g Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iF4EAREIAAYFAk74PAoACgkQFq+eroFS7PteFwD/e2e0tO++pmEnWOVNIiBO4kAL J98CjOOk/QjCa3IVTmwA/is0nCJquj1paHj29NGwrV9T1GklNTWItT3pt1Hpzw5O =N+XB -----END PGP SIGNATURE----- --xbjSOCWVZ1q9zj4g-- From owner-freebsd-rc@FreeBSD.ORG Mon Dec 26 09:52:50 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 BE8B61065680; Mon, 26 Dec 2011 09:52:50 +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 D220E8FC13; Mon, 26 Dec 2011 09:52:25 +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:References:Message-ID:Subject:Cc:To:From:Date; bh=1zj2P/KialEkM6MZMF01nYmewc3C4h3cuiAUEo/QzKU=; b=FLQ3nPApb/jWB2vlmVh1Q/+RyH/J/dTHv+PeUhcDe26+GIv6XdkGcip2dkMqCW0ujck8AXMMpxjvHLvnjPgbzcmNyfOK7Kb5XFyn273NcZjib97vYTnUwaKBVhzVEt7Cf4MxdXZJPBFAAz6rOR62uLRKC3AVy+CVS8C65Q2ExgpFQK9tIIP6/UJGTke57WbNEkrOOJUvQPNiiWOgCH2RUjNzr2n4Dk7xPbesRFKf5gXYroC3+K0p6mcmY/Fx5PM7TyQIM+Vvm2TJ5ZLIwVeqlFdr4pZ4O/rC9dx8BAN8yfKBz33uIR8Pez7Fm68TWraq5NrtO1/FA3JfjmXu+Z+c3Q==; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1Rf7EG-000JwZ-Bw; Mon, 26 Dec 2011 12:52:24 +0300 Date: Mon, 26 Dec 2011 13:52:21 +0400 From: Eygene Ryabinkin To: Doug Barton Message-ID: References: <4EF6401E.3080902@FreeBSD.org> <20111224215649.GA12789@stack.nl> <4EF80CA7.3070303@FreeBSD.org> <4EF82E3B.6040601@FreeBSD.org> <4EF833B7.9040704@FreeBSD.org> <0A59E5CD-3598-41B0-A707-6C5185E80043@gmail.com> <4EF83A59.8080008@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="+epxrXWOh++2HLjY" Content-Disposition: inline In-Reply-To: <4EF83A59.8080008@FreeBSD.org> Sender: rea@codelabs.ru Cc: Pyun Yong-Hyeon , d@delphij.net, Garrett Cooper , Gleb Smirnoff , freebsd-rc@freebsd.org 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: Mon, 26 Dec 2011 09:52:50 -0000 --+epxrXWOh++2HLjY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Mon, Dec 26, 2011 at 01:11:53AM -0800, Doug Barton wrote: > On 12/26/2011 01:02, Garrett Cooper wrote: > > $ svn log -r 226879=20 > > ------------------------------------------------------------------------ > > > >=20 > r226879 | rea | 2011-10-27 23:03:38 -0700 (Thu, 27 Oct 2011) | 10 lines > >=20 > > Fix handling of rc_force in /etc/rc.d/dhclient > >=20 > > Variable 'rc_force' is accessible only at the time of > > rc_run_command, so it can't be examined from the script's main code. > >=20 > > Spotted by: hrs Reviewed by: hrs, des Approved by: des MFC after: 2 > > weeks=20 > > ------------------------------------------------------------------------ > > > > It simply didn't exist before this change; before it was just a > > 'return 1', which is illegal outside of functions, amongst other > > things. > > Ok, so I think here is some of the source of the confusion: Unlikely that the confusion will come from my side: I know how return acts (it terminates the current context and returns to the caller) and how exit acts -- it just terminates the current process. Why can I substitute 'return 1' for 'err 1' in this case is explained below. > "The syntax of the return command is >=20 > return [exitstatus] >=20 > It terminates the current executional scope, returning from the previous > nested function, sourced script, or shell instance, in that order. The > return command is implemented as a special built-in command." >=20 > It's actually used often'ish in rc.d where exit cannot be. The whole story is the following one. My original fix, http://svnweb.freebsd.org/base/head/etc/rc.d/dhclient?r1=3D226345&r2=3D226= 464 has 'return 1' from the top-level scope of dhclient script. At this scope it is just equal to 'exit 1', unless someone does ". /etc/rc.d/dhclie= nt" as /etc/rc used to do. But current version of run_rc_script does not source the scripts that aren't ended in .sh, but spawns the subprocess for each on= e. Moreover, script names ending in .sh are currently deprecated inside rc.sub= r. So, for this case 'return 1' =3D=3D 'exit 1': {{{ $ sh -x 1.sh || echo "failed" + trap 'echo Going away' 0 + return 1 + echo Going away Going away failed $ sh -x 2.sh || echo "failed" + trap 'echo Going away' 0 + exit 1 + echo Going away Going away failed }}} But r226464 wasn't good enough, because rc_force is set only when the rc.d command hooks are executed, thus it isn't set on the top-level context of rc.d scripts. So there goes r226879, http://svnweb.freebsd.org/base/head/etc/rc.d/dhclient?r1=3D226464&r2=3D22= 6879 that introduced dhclient_pre_check _and_ the "err" call we're arguing about. Here the historical retrospection ends. > > So I vote to just remove the message (convert the err 1 to a exit 1) >=20 > I haven't dug into it yet, but if it was a return previously it almost > certainly should not be an exit now. Doug, I may be blunt now, but how can one ever say something about the code that he hasn't digged into? I know about the common sense, but it alone can't be applied to the non-trivial problems with any hope for good results. > I'll dig into the original change more tomorrow, now that it's clear > what we're actually dealing with. Very good, thanks a lot! > Thanks to both of you for helping to make it clear. My pleasure ;)) --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --+epxrXWOh++2HLjY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iF4EAREIAAYFAk74Q9UACgkQFq+eroFS7PvOQAEAjd1oAqK8e6jyz8Ssx5UTWfbm aNX/O1Xat1a53UItDlwA/3htbnQdQ0CZ1LiFWWYOeE2f6j/r4tCFClVLHHRHn3LX =LgQc -----END PGP SIGNATURE----- --+epxrXWOh++2HLjY-- From owner-freebsd-rc@FreeBSD.ORG Mon Dec 26 11:07:15 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 018371065670 for ; Mon, 26 Dec 2011 11:07:15 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E21E88FC18 for ; Mon, 26 Dec 2011 11:07:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pBQB7Egu022596 for ; Mon, 26 Dec 2011 11:07:14 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pBQB7Ei7022594 for freebsd-rc@FreeBSD.org; Mon, 26 Dec 2011 11:07:14 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 26 Dec 2011 11:07:14 GMT Message-Id: <201112261107.pBQB7Ei7022594@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-rc@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-rc@FreeBSD.org 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 11:07:15 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/163508 rc [rc.subr] [patch] Add "enable" and "disable" commands o conf/163488 rc Confusing explanation in defaults/rc.conf o conf/163321 rc [rc.conf] [patch] allow _fib syntax in rc.conf o conf/162642 rc .sh scripts in /usr/local/etc/rc.d get executed, not s o conf/161107 rc [rc] stop_boot in mountcritlocal usage is incorrect. o conf/160403 rc [rc] [patch] concurrently running rc-scripts during bo o conf/160240 rc rc.d/mdconfig and mdconfig2 should autoset $_type to v o conf/159846 rc [rc.conf] routing_stop_inet6() logic doesn't handle ip o conf/158557 rc [patch] /etc/rc.d/pf broken messages o conf/158127 rc [patch] remount_optional option in rc.initdiskless doe o conf/154554 rc [rc.d] [patch] statd and lockd fail to start o conf/153666 rc [rc.d][patch] mount filesystems from fstab over zfs da o conf/153200 rc post-boot /etc/rc.d/network_ipv6 start can miss neighb o conf/153123 rc [rc] [patch] add gsched rc file to automatically inser o conf/150474 rc [patch] rc.d/accounting: Add ability to set location o o conf/149867 rc [PATCH] rc.d script to manage multiple FIBS (kern opti o conf/149831 rc [PATCH] add support to /etc/rc.d/jail for delegating Z o conf/148656 rc rc.firewall(8): {oip} and {iip} variables in rc.firewa o conf/147685 rc [rc.d] [patch] new feature for /etc/rc.d/fsck o conf/147444 rc [rc.d] [patch] /etc/rc.d/zfs stop not called on reboot o conf/146053 rc [patch] [request] shutdown of jails breaks inter-jail o conf/145445 rc [rc.d] error in /etc/rc.d/jail (bad logic) o conf/145440 rc [rc.d] [patch] add multiple fib support (setfib) in /e o conf/145399 rc [patch] rc.d scripts are unable to start/stop programs o conf/145009 rc [patch] rc.subr(8): rc.conf should allow mac label con o conf/144213 rc [rc.d] [patch] Disappearing zvols on reboot o conf/143637 rc [patch] ntpdate(8) support for ntp-servers supplied by o conf/143085 rc [patch] ftp-proxy(8) rc(8) with multiple instances o conf/143084 rc [jail] [patch]: fix rc.d/jail creating stray softlinks o conf/142973 rc [jail] [patch] Strange counter init value in jail rc o conf/142434 rc [patch] Add cpuset(1) support to rc.subr(8) o conf/142304 rc rc.conf(5): mdconfig and mdconfig2 rc.d scripts lack e o conf/141909 rc rc.subr(8): [patch] add rc.conf.d support to /usr/loca o conf/141907 rc [rc.d] Bug if mtu (maybe others?) is set as first argu o conf/141678 rc [patch] A minor enhancement to how /etc/rc.d/jail dete o conf/141275 rc [request] dhclient(8) rc script should print something o conf/140440 rc [patch] allow local command files in rc.{suspend,resum o conf/140261 rc [patch] Improve flexibility of mdconfig2 startup scrip o conf/138208 rc [rc.d] [patch] Making rc.firewall (workstation) IPv6 a o conf/137629 rc [rc.d] background_dhclient rc.conf option causing doub o conf/137470 rc [PATCH] /etc/rc.d/mdconfig2 : prioritize cli parameter o conf/137271 rc [rc.d] Cannot update /etc/host.conf when root filesyst o conf/136624 rc [rc.d] sysctl variables for ipnat are not applied on b o conf/135338 rc [rc.d] pf startup order seems broken [regression] o conf/134918 rc [patch] rc.subr fails to detect perl daemons o conf/134660 rc [patch] rc-script for initializing ng_netflow+ng_ipfw o conf/134333 rc PPP configuration problem in the rc.d scripts in combi o conf/134006 rc [patch] Unload console screensaver kernel modules if s o conf/133890 rc [patch] sshd(8): add multiple profiles to the rc.d scr o conf/132483 rc rc.subr(8) [patch] setfib(1) support for rc.subr o conf/132476 rc [rc.d] [patch] add support setfib(1) in rc.d/routing o conf/128299 rc [patch] /etc/rc.d/geli does not mount partitions using o conf/126392 rc [patch] rc.conf ifconfig_xx keywords cannot be escaped p bin/126324 rc [patch] rc.d/tmp: Prevent mounting /tmp in second tim o conf/124747 rc [patch] savecore can't create dump from encrypted swap o conf/124248 rc [jail] [patch] add support for nice value for rc.d/jai o conf/123734 rc [patch] Chipset VIA CX700 requires extra initializatio o conf/123222 rc [patch] Add rtprio(1)/idprio(1) support to rc.subr(8). o conf/123119 rc [patch] rc script for ipfw does not handle IPv6 o conf/122968 rc [rc.d] /etc/rc.d/addswap: md swapfile multiplication a o conf/122477 rc [patch] /etc/rc.d/mdconfig and mdconfig2 are ignoring o conf/122170 rc [patch] [request] New feature: notify admin via page o o kern/121566 rc [nfs] [request] [patch] ethernet iface should be broug o conf/120431 rc [patch] devfs.rules are not initialized under certain o conf/120406 rc [devd] [patch] Handle newly attached pcm devices (eg. o conf/119874 rc [patch] "/etc/rc.d/pf reload" fails if there are macro o conf/119076 rc [patch] [rc.d] /etc/rc.d/netif tries to remove alias a o bin/118325 rc [patch] [request] new periodic script to test statuses o conf/118255 rc savecore never finding kernel core dumps (rcorder prob o conf/117935 rc [patch] ppp fails to start at boot because of missing o conf/113915 rc [patch] ndis wireless driver fails to associate when i o conf/109980 rc /etc/rc.d/netif restart doesn't destroy cloned_interfa o conf/109562 rc [rc.d] [patch] [request] Make rc.d/devfs usable from c o conf/109272 rc [request] increase default rc shutdown timeout o conf/108589 rc rtsol(8) fails due to default ipfw rules o conf/106009 rc [ppp] [patch] [request] Fix pppoed startup script to p o conf/105689 rc [ppp] [request] syslogd starts too late at boot o conf/105145 rc [ppp] [patch] [request] add redial function to rc.d/pp o conf/104549 rc [patch] rc.d/nfsd needs special _find_processes functi o conf/102700 rc [geli] [patch] Add encrypted /tmp support to GELI/GBDE o conf/99721 rc [patch] /etc/rc.initdiskless problem copy dotfile in s o conf/99444 rc [patch] Enhancement: rc.subr could easily support star o conf/96343 rc [patch] rc.d order change to start inet6 before pf o conf/93815 rc [patch] Adds in the ability to save ipfw rules to rc.d o conf/92523 rc [patch] allow rc scripts to kill process after a timeo o conf/89870 rc [patch] [request] make netif verbose rc.conf toggle o conf/88913 rc [patch] wrapper support for rc.subr o conf/85819 rc [patch] script allowing multiuser mode in spite of fsc o kern/81006 rc ipnat not working with tunnel interfaces on startup o conf/77663 rc Suggestion: add /etc/rc.d/addnetswap after addcritremo o conf/73677 rc [patch] add support for powernow states to power_profi o conf/58939 rc [patch] dumb little hack for /etc/rc.firewall{,6} o conf/56934 rc [patch] rc.firewall rules for natd expect an interface o conf/44170 rc [patch] Add ability to run multiple pppoed(8) on start 94 problems total. From owner-freebsd-rc@FreeBSD.ORG Mon Dec 26 17:27:08 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 7F491106566B; Mon, 26 Dec 2011 17:27:08 +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 1883E8FC19; Mon, 26 Dec 2011 17:27:07 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so15223998vbb.13 for ; Mon, 26 Dec 2011 09:27:07 -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=khMGsYu993dixmZF0SnSNWOdcwYCTrFSjvJVhZENMg0=; b=n0V2UZCpT3vOAQtnF3fdjKTCOcz+DXE9GeeZYxb027Cz5IxP/2XNzardiK4Gh8OD8X LztooFb3eWIXaoAb37uRhLERXHTY3Q+Etf4KiZug0Z+RKS66yhz7rnGIBjysGBEZtXgs 4iqBGoYcbbdEsi2/DEFA7G2S7xbePe0bj8vFY= Received: by 10.52.177.38 with SMTP id cn6mr12232128vdc.8.1324920427338; Mon, 26 Dec 2011 09:27:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.29.225 with HTTP; Mon, 26 Dec 2011 09:26:46 -0800 (PST) In-Reply-To: <4EF8105D.3030907@FreeBSD.org> References: <201112241230.pBOCUF3h064098@freefall.freebsd.org> <4EF64915.4030006@FreeBSD.org> <4EF8105D.3030907@FreeBSD.org> From: Maxim Ignatenko Date: Mon, 26 Dec 2011 19:26: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: Mon, 26 Dec 2011 17:27:08 -0000 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 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. =C2=A0It 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. =C2=A0I just don't care. =C2=A0The fact that oth= ers >> 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 in th= e >> tree where bar_enable=3Dyes forces foo_enable=3Dyes 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=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. > 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, foo_enable=3DNO gets added to the end of last processed file and we still have foo enabled. From owner-freebsd-rc@FreeBSD.ORG Tue Dec 27 00:12:02 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 18A1D106566C for ; Tue, 27 Dec 2011 00:12:02 +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 979B5178F5E; Tue, 27 Dec 2011 00:10:15 +0000 (UTC) Message-ID: <4EF90CE7.7050008@FreeBSD.org> Date: Mon, 26 Dec 2011 16:10:15 -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: Maxim Ignatenko References: <201112241230.pBOCUF3h064098@freefall.freebsd.org> <4EF64915.4030006@FreeBSD.org> <4EF8105D.3030907@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 00:12:02 -0000 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 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/ From owner-freebsd-rc@FreeBSD.ORG Tue Dec 27 02:58:16 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 2F507106566B; Tue, 27 Dec 2011 02:58:16 +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 2B33514D902; Tue, 27 Dec 2011 02:57:46 +0000 (UTC) Message-ID: <4EF93429.4020404@FreeBSD.org> Date: Mon, 26 Dec 2011 18:57:45 -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: d@delphij.net References: <4EB6693F.2020102@delphij.net> In-Reply-To: <4EB6693F.2020102@delphij.net> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: multipart/mixed; boundary="------------070009070701000905080005" Cc: freebsd-rc@FreeBSD.ORG, Brooks Davis , Xin LI , Eygene Ryabinkin , Dag-Erling Smorgrav 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: Tue, 27 Dec 2011 02:58:16 -0000 This is a multi-part message in MIME format. --------------070009070701000905080005 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/06/2011 03:02, Xin LI wrote: > Hi, > > It seems that 226879 have introduced an error indication where if an > interface is up and is not set to DHCP, the devd invoked > /etc/rc.d/dhclient wlan0 call would generate an annoying message. > > I think this message is not necessary at all -- normally > /etc/rc.d/dhclient is used by the system and it's just legitimate that > a network interface comes up and have not assigned as DHCP. > > I'd like to propose the attached change, which turns this message into > debug message but keep the exit intact. The discussion about changing the error message in rc.d/dhclient is applying the fix to the wrong location. Thanks to Eygene's help in understanding the history of where the error message came from I have what I believe to be a better suggestion. History: Prior to, and after, des' changes in r226345 and r226464 if rc.d/dhclient was called for a non-DHCP interface it returned with exit code 1, but without an error. What des added was an additional test for whether or not rc_force is set. This is a feature, because it allows one to do 'service dhclient forcestart em0' and have DHCP configuration attempted even if it's not configured in rc.conf. In r226879 rea astutely observed that rc_force is only visible in certain contexts, and added a better check for that. He also added an error message that did not previously exist. The Problem: /etc/rc.d/dhclient is called unconditionally from devd.conf every time the interface comes up. If the interface is not configured to use DHCP, this generates an error in the logs that did not exist prior to r226879. My proposed solution: Make devd.conf smarter about how it tries to bring the interface up. This is accomplished rather easily in the attached patch, which uses netif instead of dhclient. The virtue of this solution is that it will use whatever configuration exists for the interface, and will not call rc.d/dhclient spuriously. Brooks added the dhclient invocation to devd.conf in r147088 back in 2005-06-06. I've cc'ed him to ask if there is any obvious reason why using netif instead wouldn't be a good idea. hth, Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ --------------070009070701000905080005 Content-Type: text/plain; name="devd.conf.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="devd.conf.diff" Index: devd.conf =================================================================== --- devd.conf (revision 228906) +++ devd.conf (working copy) @@ -44,16 +44,14 @@ }; # -# 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. +# Try to start the network on Ethernet-like interfaces when the link comes +# up. # notify 0 { match "system" "IFNET"; match "type" "LINK_UP"; media-type "ethernet"; - action "/etc/rc.d/dhclient quietstart $subsystem"; + action "/etc/rc.d/netif quietstart $subsystem"; }; # @@ -73,7 +71,7 @@ match "system" "IFNET"; match "type" "LINK_UP"; media-type "802.11"; - action "/etc/rc.d/dhclient quietstart $subsystem"; + action "/etc/rc.d/netif quietstart $subsystem"; }; # An entry like this might be in a different file, but is included here --------------070009070701000905080005-- From owner-freebsd-rc@FreeBSD.ORG Tue Dec 27 03:17:42 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 C5B47106566C; Tue, 27 Dec 2011 03:17:42 +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 C9E6B14EE42; Tue, 27 Dec 2011 03:17:41 +0000 (UTC) Message-ID: <4EF938D5.7060801@FreeBSD.org> Date: Mon, 26 Dec 2011 19:17:41 -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: <4EF6401E.3080902@FreeBSD.org> <20111224215649.GA12789@stack.nl> <4EF80CA7.3070303@FreeBSD.org> <4EF82E3B.6040601@FreeBSD.org> <4EF833B7.9040704@FreeBSD.org> <0A59E5CD-3598-41B0-A707-6C5185E80043@gmail.com> <4EF83A59.8080008@FreeBSD.org> 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 , d@delphij.net, Garrett Cooper , Gleb Smirnoff , freebsd-rc@freebsd.org 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: Tue, 27 Dec 2011 03:17:42 -0000 On 12/26/2011 01:52, Eygene Ryabinkin wrote: > Mon, Dec 26, 2011 at 01:11:53AM -0800, Doug Barton wrote: >> On 12/26/2011 01:02, Garrett Cooper wrote: >>> $ svn log -r 226879 >>> ------------------------------------------------------------------------ >>> >>> >> r226879 | rea | 2011-10-27 23:03:38 -0700 (Thu, 27 Oct 2011) | 10 lines >>> >>> Fix handling of rc_force in /etc/rc.d/dhclient >>> >>> Variable 'rc_force' is accessible only at the time of >>> rc_run_command, so it can't be examined from the script's main code. >>> >>> Spotted by: hrs Reviewed by: hrs, des Approved by: des MFC after: 2 >>> weeks >>> ------------------------------------------------------------------------ >>> >>> It simply didn't exist before this change; before it was just a >>> 'return 1', which is illegal outside of functions, amongst other >>> things. >> >> Ok, so I think here is some of the source of the confusion: > > Unlikely that the confusion will come from my side: I didn't say *you* were confused about this, I said "the confusion." :) > The whole story is the following one. Thanks for your background information. I dug through the svn logs and you are of course correct that the error message didn't exist prior to your change. However I think the error message is still valuable because it will catch problems such as: ifconfig_em0='DHPC' I just sent a response to delphij's original message with what I think is a better solution, attempt to more properly configure the interface from devd.conf in the first place. This avoids spuriously calling rc.d/dhclient. >>> So I vote to just remove the message (convert the err 1 to a exit 1) >> >> I haven't dug into it yet, but if it was a return previously it almost >> certainly should not be an exit now. > > Doug, I may be blunt now, but how can one ever say something about the > code that he hasn't digged into? I know about the common sense, but > it alone can't be applied to the non-trivial problems with any hope > for good results. Please note that I qualified my statement, precisely because I had not yet dug deeply into it. However, to answer your question "how can one ever say something about the code that he hasn't digged into?": 1. Years of experience 2. Depth of understanding of the rc.d code generally 3. A finely honed filter which detects "This smells like fixing a symptom rather than fixing the actual problem." In the end it seems that I was right, dhclient was the wrong place to address this issue. I even suggested that the proper place to fix it was in devd.conf. Now you can say that I just got lucky, but I would beg to differ. :) Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-rc@FreeBSD.ORG Tue Dec 27 03:18:51 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 24A04106564A; Tue, 27 Dec 2011 03:18:51 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id AB5868FC0C; Tue, 27 Dec 2011 03:18:50 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pBR3CND8032060 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 26 Dec 2011 20:12:23 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) From: Warner Losh In-Reply-To: <4EF93429.4020404@FreeBSD.org> Date: Mon, 26 Dec 2011 20:12:13 -0700 Message-Id: <78816734-18BA-4B1D-9551-DBD1D9F83716@bsdimp.com> References: <4EB6693F.2020102@delphij.net> <4EF93429.4020404@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Mon, 26 Dec 2011 20:12:23 -0700 (MST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Brooks Davis , freebsd-rc@freebsd.org, Eygene Ryabinkin , Dag-Erling Smorgrav , Xin LI , Xin LI 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: Tue, 27 Dec 2011 03:18:51 -0000 On Dec 26, 2011, at 7:57 PM, Doug Barton wrote: > I like this patch, but only as one of the originators of the original = kludge. At the time I did it, rcng wasn't as well defined as things are = today. If this correction is needed, I'm all for it. Warner From owner-freebsd-rc@FreeBSD.ORG Tue Dec 27 03:25:01 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 7ABFD106564A; Tue, 27 Dec 2011 03:25:01 +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 E09AD14FA64; Tue, 27 Dec 2011 03:24:58 +0000 (UTC) Message-ID: <4EF93A8A.8000204@FreeBSD.org> Date: Mon, 26 Dec 2011 19:24:58 -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: Warner Losh References: <4EB6693F.2020102@delphij.net> <4EF93429.4020404@FreeBSD.org> <78816734-18BA-4B1D-9551-DBD1D9F83716@bsdimp.com> In-Reply-To: <78816734-18BA-4B1D-9551-DBD1D9F83716@bsdimp.com> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Brooks Davis , freebsd-rc@freebsd.org, Eygene Ryabinkin , Dag-Erling Smorgrav , Xin LI , Xin LI 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: Tue, 27 Dec 2011 03:25:01 -0000 On 12/26/2011 19:12, Warner Losh wrote: > > On Dec 26, 2011, at 7:57 PM, Doug Barton wrote: > >> > > I like this patch, but only as one of the originators of the original > kludge. At the time I did it, rcng wasn't as well defined as things are > today. If this correction is needed, I'm all for it. Thank you for looking it over. You're correct that at the time the call to dhclient was added to devd.conf (6.5 years ago) the feature of netif that allows configuration of 1 interface at a time was still new'ish, and not quite fully congealed. Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-rc@FreeBSD.ORG Tue Dec 27 04:37:04 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 569D1106566C; Tue, 27 Dec 2011 04:37:04 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id EFAB78FC08; Tue, 27 Dec 2011 04:37:03 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so15488717vcb.13 for ; Mon, 26 Dec 2011 20:37:03 -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=iJo9tHsqjXd9MVAXUk4RR6lEhHMOaFw3rEircX5U4hg=; b=ZqGDYUJ1pB8wIg9A58c19WdzLFRDNA5JBc1j0R1F+IIGVi0ihC8c0wBSvhcHPp0SvX mueL4RXAG1d641DQnX8seTgGnmuFQdyvevSZ2KKXGUnMEEuOJxvjwebN/1BtxSQbyfH1 wPCOS+WAkVOvtdBZadt7ml0fCopkvcqpfrw0Y= Received: by 10.221.13.196 with SMTP id pn4mr16855779vcb.74.1324960623269; Mon, 26 Dec 2011 20:37:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.29.225 with HTTP; Mon, 26 Dec 2011 20:36:42 -0800 (PST) In-Reply-To: <4EF90CE7.7050008@FreeBSD.org> References: <201112241230.pBOCUF3h064098@freefall.freebsd.org> <4EF64915.4030006@FreeBSD.org> <4EF8105D.3030907@FreeBSD.org> <4EF90CE7.7050008@FreeBSD.org> From: Maxim Ignatenko Date: Tue, 27 Dec 2011 06:36:42 +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 04:37:04 -0000 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 rejec= t 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 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. =C2=A0I just don't care. =C2=A0The fact that o= thers >>>> 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 in = the >>>> tree where bar_enable=3Dyes forces foo_enable=3Dyes 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 sa= y >>> 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. >>> >> >> 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?)? From owner-freebsd-rc@FreeBSD.ORG Tue Dec 27 04:49:54 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 9ABD8106564A; Tue, 27 Dec 2011 04:49:54 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 536688FC08; Tue, 27 Dec 2011 04:49:54 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pBR4jBGC032584 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 26 Dec 2011 21:45:11 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4EF93A8A.8000204@FreeBSD.org> Date: Mon, 26 Dec 2011 21:45:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EB6693F.2020102@delphij.net> <4EF93429.4020404@FreeBSD.org> <78816734-18BA-4B1D-9551-DBD1D9F83716@bsdimp.com> <4EF93A8A.8000204@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Mon, 26 Dec 2011 21:45:12 -0700 (MST) Cc: Brooks Davis , freebsd-rc@freebsd.org, Eygene Ryabinkin , Dag-Erling Smorgrav , Xin LI , Xin LI 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: Tue, 27 Dec 2011 04:49:54 -0000 On Dec 26, 2011, at 8:24 PM, Doug Barton wrote: > On 12/26/2011 19:12, Warner Losh wrote: >>=20 >> On Dec 26, 2011, at 7:57 PM, Doug Barton wrote: >>=20 >>> >>=20 >> I like this patch, but only as one of the originators of the original >> kludge. At the time I did it, rcng wasn't as well defined as things = are >> today. If this correction is needed, I'm all for it. >=20 > Thank you for looking it over. You're correct that at the time the = call > to dhclient was added to devd.conf (6.5 years ago) the feature of = netif > that allows configuration of 1 interface at a time was still new'ish, > and not quite fully congealed. Yea, this actually replaces a mechanism that was used in pccardd that = dates back about 10 or more years. When devd.conf replaced pccardd, we = tried to map it as closely as possible and get rid of the (poorly named) = pccard_ether script... I haven't looked into the deeper issue of the bogus error messages, or = if they are bogus at all or not... Warner From owner-freebsd-rc@FreeBSD.ORG Tue Dec 27 05:03:24 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 2C8561065670 for ; Tue, 27 Dec 2011 05:03:24 +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 CF01314E0BD; Tue, 27 Dec 2011 05:03:23 +0000 (UTC) Message-ID: <4EF9519B.8090409@FreeBSD.org> Date: Mon, 26 Dec 2011 21:03:23 -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: Maxim Ignatenko References: <201112241230.pBOCUF3h064098@freefall.freebsd.org> <4EF64915.4030006@FreeBSD.org> <4EF8105D.3030907@FreeBSD.org> <4EF90CE7.7050008@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 05:03:24 -0000 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 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. > > 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? -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-rc@FreeBSD.ORG Tue Dec 27 06:32:14 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 3536E1065672; Tue, 27 Dec 2011 06:32:14 +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 A9A888FC08; Tue, 27 Dec 2011 06:32:13 +0000 (UTC) Received: by yhfq46 with SMTP id q46so8614184yhf.13 for ; Mon, 26 Dec 2011 22:32:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ejIFZc4jYbVgq6Mc+NU5G6w2ELGLz/mqQtAZc9ySwvY=; b=oShkAFP9GNSNBv/GvGx+o8jSoJ8/HXMMC0rvfrkpY86fqckHIZWjXMeseN2ORBh6Hp Mv25XaI3rderG7KSjXZsBXDNJrFFsM0kkeP6w+IHY/1kT2IgocnnOL7hc3dZWYuQRrcG KrOHLFqaCzKMEYo8CcL6OiLn4lUrHKPSDU69I= Received: by 10.236.173.131 with SMTP id v3mr36191933yhl.112.1324967532663; Mon, 26 Dec 2011 22:32:12 -0800 (PST) Received: from [192.168.2.5] (dpc691944246.direcpc.com. [69.19.44.246]) by mx.google.com with ESMTPS id m38sm64195216anq.16.2011.12.26.22.31.57 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Dec 2011 22:32:12 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Garrett Cooper In-Reply-To: <4EF93429.4020404@FreeBSD.org> Date: Mon, 26 Dec 2011 22:31:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EB6693F.2020102@delphij.net> <4EF93429.4020404@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1251.1) Cc: Brooks Davis , freebsd-rc@FreeBSD.ORG, Eygene Ryabinkin , Dag-Erling Smorgrav , d@delphij.net, Xin LI 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: Tue, 27 Dec 2011 06:32:14 -0000 On Dec 26, 2011, at 6:57 PM, Doug Barton wrote: > On 11/06/2011 03:02, Xin LI wrote: >> Hi, >>=20 >> It seems that 226879 have introduced an error indication where if an >> interface is up and is not set to DHCP, the devd invoked >> /etc/rc.d/dhclient wlan0 call would generate an annoying message. >>=20 >> I think this message is not necessary at all -- normally >> /etc/rc.d/dhclient is used by the system and it's just legitimate = that >> a network interface comes up and have not assigned as DHCP. >>=20 >> I'd like to propose the attached change, which turns this message = into >> debug message but keep the exit intact. >=20 > The discussion about changing the error message in rc.d/dhclient is > applying the fix to the wrong location. Thanks to Eygene's help in > understanding the history of where the error message came from I have > what I believe to be a better suggestion. >=20 > History: >=20 > Prior to, and after, des' changes in r226345 and r226464 if > rc.d/dhclient was called for a non-DHCP interface it returned with = exit > code 1, but without an error. What des added was an additional test = for > whether or not rc_force is set. This is a feature, because it allows = one > to do 'service dhclient forcestart em0' and have DHCP configuration > attempted even if it's not configured in rc.conf. >=20 > In r226879 rea astutely observed that rc_force is only visible in > certain contexts, and added a better check for that. He also added an > error message that did not previously exist. >=20 > The Problem: >=20 > /etc/rc.d/dhclient is called unconditionally from devd.conf every time > the interface comes up. If the interface is not configured to use = DHCP, > this generates an error in the logs that did not exist prior to = r226879. >=20 > My proposed solution: >=20 > Make devd.conf smarter about how it tries to bring the interface up. > This is accomplished rather easily in the attached patch, which uses > netif instead of dhclient. The virtue of this solution is that it will > use whatever configuration exists for the interface, and will not call > rc.d/dhclient spuriously. >=20 > Brooks added the dhclient invocation to devd.conf in r147088 back in > 2005-06-06. I've cc'ed him to ask if there is any obvious reason why > using netif instead wouldn't be a good idea. The only misgiving that I have about this is that it deletes the = default route and might cause issues with firewalls, natd, more = complicated interface types like laggs, vlans, etc. It annoys me that = torquing the network via rc.d ties FreeBSD into knots still today :(. I'll gladly test this out when I get a chance though sometime = this week. Thanks, -Garrett= From owner-freebsd-rc@FreeBSD.ORG Tue Dec 27 06:42:05 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 B99A71065672; Tue, 27 Dec 2011 06:42:05 +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 E90778FC1B; Tue, 27 Dec 2011 06:39:13 +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:References:Message-ID:Subject:Cc:To:From:Date; bh=uWwWS1keGWdYEc3dxfcyRMeH9uxoR/utJPADQmvdPGs=; b=AjVwvBsWV3AG+uwHZlX+qZFtLBKw7kXQBlb9MMSZPmTrT1+oZk1+2ypXzqqlhD8C98DmxmjHJLFdr7cyNqiqOok0tF2/FDy7pVM+/IiSSDxcCjCy3T5CQDAlCIn4NLGB+IO6U0x0J2/MRkXhSkRUV9C5yDW94MCa+TdLmcTUDLGxHSrmkyx/IO6qoUPS/q/p6FBWE9qtEKaqm+4xFq3mt+pQ61Nk6TvtaTTOVaQVUfk4uHDrKJSY5U8E4CuXxawr4/YZc5a4K1rvpz29zXvnluqdiUpg6K0Wyy5SOChqWTzHZuE9DogfmvUN6h0tEvbJCjMDVATvRAFMNziTJnonHQ==; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1RfQgp-000LJb-00; Tue, 27 Dec 2011 09:39:11 +0300 Date: Tue, 27 Dec 2011 10:39:07 +0400 From: Eygene Ryabinkin To: Doug Barton Message-ID: References: <4EB6693F.2020102@delphij.net> <4EF93429.4020404@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ubBGeysJ7fFOU9Y9" Content-Disposition: inline In-Reply-To: <4EF93429.4020404@FreeBSD.org> Sender: rea@codelabs.ru Cc: Pyun Yong-Hyeon , Brooks Davis , freebsd-rc@FreeBSD.ORG, Gleb Smirnoff , Dag-Erling Smorgrav , d@delphij.net, Xin LI 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: Tue, 27 Dec 2011 06:42:05 -0000 --ubBGeysJ7fFOU9Y9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Doug, good day. Mon, Dec 26, 2011 at 06:57:45PM -0800, Doug Barton wrote: > My proposed solution: >=20 > Make devd.conf smarter about how it tries to bring the interface up. > This is accomplished rather easily in the attached patch, which uses > netif instead of dhclient. The virtue of this solution is that it will > use whatever configuration exists for the interface, and will not call > rc.d/dhclient spuriously. This solution will also do the work, but I am slightly concerned that it will - call all netif machinery for interfaces with static IPs: it will be useless for already-configured interfaces; - in the case of vlan interfaces, ifconfig dance will be done twice for each of them: once from the netif for the parent interface and once for each vlan in turn. This will just do the work that is useless in all-static configuration. Worse, this solution will ruin host's connectivity in the following scenario: - one runs his remote server with all static configuration and strict, default-to-deny firewall configuration (call this person "Eygene Ryabinkin"); - his upstream provider tells him: listen, we're rearranging our IP space and you should change IP1 to IP2; - administrator is busy changing the configuration of his host; his plan is to substitute IP1 to IP2 everywhere and to reboot his machine to cleanly acquire IP2 and continue operations; - he already substituted IP1 -> IP2 in rc.conf and starts poking the firewall configuration, but here comes the link down event due to the $PROVIDER who reconfigures his $CISCO or whatever; - the system ends up in an unusable state, because link up event will change interface's IP, but firewall isn't ready for this and isn't allowing connections to IP2, but allows them only for IP1 that is already gone from the interface due to devd and netif script. Here's the demo that changes in rc.conf will unconditionally change interface's IP regardless of the current setting: {{{ $ grep ifconfig_sk0 /etc/rc.conf ifconfig_sk0=3D"inet 10.0.0.1/24" $ service netif quietstart sk0 Starting Network: sk0. sk0: flags=3D8843 metric 0 mtu 1500 options=3D80009 ether 00:22:15:6e:9d:a9 inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255 media: Ethernet autoselect (none) status: no carrier $ grep ifconfig_sk0 /etc/rc.conf ifconfig_sk0=3D"inet 10.0.0.2/24" $ service netif quietstart sk0 Starting Network: sk0. sk0: flags=3D8843 metric 0 mtu 1500 options=3D80009 ether 00:22:15:6e:9d:a9 inet 10.0.0.2 netmask 0xffffff00 broadcast 10.0.0.255 media: Ethernet autoselect (1000baseT ) status: active }}} People may tell me that - Eygene Ryabinkin should run firewall configuration whose knowledge of IP for the interface is based on the automagic like ipfw's "me" verb; - Eygene Ryabinkin should not work with the remote host without access to its physical console via remote KVM or alike; - Eygene Ryabinkin should not run remote servers at all (just kidding). I am aware of these fine points, however my meat is that static IP configuration is the _static_ one (cool assertion, isn't it?). But it has at least one consequence: people view their static IP configurations as a really static ones and tend to think that only their direct actions will change them. So, any non-atomic changes in configuration won't be regarded as a problem: only direct actions that will initiate the reconfiguration of the network interfaces must change the stuff and changes in configuration files that aren't supplemented with such actions must not change anything. Your way to fix the problem adds the possibility of the linkdown/linkup event combo to alter the configuration that is in the process of being changed. That's unexpected and one can't be ready for it in all situations (though remote console will save some brain cells): it depends on the external factor one can't fully control. Linkup/linkdown events aren't that rare and generally they are not viewed as something unusual that will ruin people's connectivity: as long as L3 layer and above will stay alive, link flaps on L2 shouldn't change its operations apart from outages for the flap duration. So, my motto here is "Static is static, leave it alone and don't make it to depend on the dynamic events; DHCP is the dynamic protocol by its nature, so it can depend on the dynamic events". --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --ubBGeysJ7fFOU9Y9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iF4EAREIAAYFAk75aAsACgkQFq+eroFS7PvnPAEAiRhMcXufLdgZwaGH5cPjMpSl rg2pLNG2LR36EUbCbIcA/iWOph3i8hzqZKPAcrSMH1oxkRfs9S/GKWDrnu1LOV53 =He07 -----END PGP SIGNATURE----- --ubBGeysJ7fFOU9Y9-- From owner-freebsd-rc@FreeBSD.ORG Tue Dec 27 07:02:22 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 1B97D106566B; Tue, 27 Dec 2011 07:02:22 +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 69C3F152B01; Tue, 27 Dec 2011 07:02:21 +0000 (UTC) Message-ID: <4EF96D7D.3030701@FreeBSD.org> Date: Mon, 26 Dec 2011 23:02:21 -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: Garrett Cooper References: <4EB6693F.2020102@delphij.net> <4EF93429.4020404@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Brooks Davis , freebsd-rc@FreeBSD.ORG, Eygene Ryabinkin , Dag-Erling Smorgrav , d@delphij.net, Xin LI 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: Tue, 27 Dec 2011 07:02:22 -0000 On 12/26/2011 22:31, Garrett Cooper wrote: > The only misgiving that I have about this is that it deletes the > default route Um, I'm not sure how it would do that. Can you fill me in? > and might cause issues with firewalls, natd, more > complicated interface types like laggs, vlans, etc. We would need a bit of educational material to let people know that what's in rc.conf will go live when they type 'ifconfig up,' sure. I would imagine that most folks would view that as a feature. :) Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-rc@FreeBSD.ORG Tue Dec 27 07:21:09 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 3D402106564A; Tue, 27 Dec 2011 07:21:09 +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 B855914FE38; Tue, 27 Dec 2011 07:21:08 +0000 (UTC) Message-ID: <4EF971E4.4050905@FreeBSD.org> Date: Mon, 26 Dec 2011 23:21:08 -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: <4EB6693F.2020102@delphij.net> <4EF93429.4020404@FreeBSD.org> 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 , Brooks Davis , freebsd-rc@FreeBSD.ORG, Gleb Smirnoff , Dag-Erling Smorgrav , d@delphij.net, Xin LI 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: Tue, 27 Dec 2011 07:21:09 -0000 On 12/26/2011 22:39, Eygene Ryabinkin wrote: > Doug, good day. > > Mon, Dec 26, 2011 at 06:57:45PM -0800, Doug Barton wrote: >> My proposed solution: >> >> Make devd.conf smarter about how it tries to bring the interface up. >> This is accomplished rather easily in the attached patch, which uses >> netif instead of dhclient. The virtue of this solution is that it will >> use whatever configuration exists for the interface, and will not call >> rc.d/dhclient spuriously. > > This solution will also do the work, but I am slightly concerned that it > will > > - call all netif machinery for interfaces with static IPs: The machinery is not that big/complex. > it will be useless for already-configured interfaces; It also won't harm anything. > - in the case of vlan interfaces, ifconfig dance will be done twice > for each of them: once from the netif for the parent interface and > once for each vlan in turn. Are you certain that the devd.conf trigger will fire when a vlan is up'ed? > This will just do the work that is useless in all-static configuration. I'm not sure I agree that it's useless. I can actually see this as quite handy. Personally I try to be in the habit of adding the configuration to rc.conf first, and using netif to start the interface so that I know for sure what will happen when that host reboots. > Worse, this solution will ruin host's connectivity in the following > scenario: > > - one runs his remote server with all static configuration and strict, > default-to-deny firewall configuration (call this person "Eygene > Ryabinkin"); > > - his upstream provider tells him: listen, we're rearranging our IP > space and you should change IP1 to IP2; > > - administrator is busy changing the configuration of his host; his > plan is to substitute IP1 to IP2 everywhere and to reboot his > machine to cleanly acquire IP2 and continue operations; > > - he already substituted IP1 -> IP2 in rc.conf and starts poking > the firewall configuration, but here comes the link down event > due to the $PROVIDER who reconfigures his $CISCO or whatever; > > - the system ends up in an unusable state, because link up event > will change interface's IP, but firewall isn't ready for this > and isn't allowing connections to IP2, but allows them only for > IP1 that is already gone from the interface due to devd and netif > script. First, I think what you're describing is a pretty small edge case. [snip demo] > People may tell me that > > - Eygene Ryabinkin should run firewall configuration whose knowledge > of IP for the interface is based on the automagic like ipfw's "me" > verb; > > - Eygene Ryabinkin should not work with the remote host without access > to its physical console via remote KVM or alike; Second, these are both valid points. :) > I am aware of these fine points, however my meat is that static IP > configuration is the _static_ one (cool assertion, isn't it?). But it > has at least one consequence: people view their static IP > configurations as a really static ones and tend to think that only their > direct actions will change them. So, any non-atomic changes in > configuration won't be regarded as a problem: only direct actions that > will initiate the reconfiguration of the network interfaces must > change the stuff and changes in configuration files that aren't > supplemented with such actions must not change anything. I agree that this change will require user education. However 'ifconfig down' and 'ifconfig up' are actually direct actions. Users who don't want this can simply comment out the entry in rc.conf, or the entry in devd.conf. > Your way to fix the problem adds the possibility of the > linkdown/linkup event combo to alter the configuration that is in the > process of being changed. That's unexpected and one can't be ready > for it in all situations (though remote console will save some brain > cells): it depends on the external factor one can't fully control. In very rare edge cases, yes. > Linkup/linkdown events aren't that rare and generally they are not > viewed as something unusual that will ruin people's connectivity: as > long as L3 layer and above will stay alive, link flaps on L2 shouldn't > change its operations apart from outages for the flap duration. But it's the combination of "unexpected L2 flap" AND "being in the process of making an rc.conf change" that will trigger the problem you describe. And once again, if the user doesn't want the change to take effect immediately they can comment it out. If no config exists for the interface, nothing bad will happen. > So, my motto here is "Static is static, leave it alone and don't make > it to depend on the dynamic events; DHCP is the dynamic protocol by > its nature, so it can depend on the dynamic events". While I don't agree that the problems you're describing are enough of a possibility to be concerned about, the other alternative that I considered is for devd.conf to call a wrapper script that first determines whether or not it's a DHCP interface, and then calls rc.d/dhclient if it is. However, there are a couple of downsides to that. First, it's more work. :) But seriously, one advantage of using netif is that it will also work with interfaces that are dynamically configured with IPv6. If we were to move to a wrapper script idea I'd like to see it support that as well as IPv4 DHCP. Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-rc@FreeBSD.ORG Tue Dec 27 09:26:57 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 EFC001065670; Tue, 27 Dec 2011 09:26:57 +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 4A87E8FC13; Tue, 27 Dec 2011 09:26:57 +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=reVtzAbOphnltwcPEXia45Zh+V3ytyrUOYTNYfGw9lk=; b=XPW7rxB8bg00wvz5nCSQ/OsCy4NctMY0IBqMpw/cvZUqL22ZOxUMszKIh0/qqEFD+Fzra5UBDKpG+v0/vMoRyv0ykX4ZAnZ5dMVPGJqOVNqzXpMtwKOCQ31RbHnOTHVpkCkrEA9KebtC/U5xTaCzIh3hOhfh83E+jIWXZYRnANY00+zR5jGxwVHJ6Qha8NKgW/V2UZ7wUMoGPhqJMPveL63JJhGLt/c+/vHthoxqE4UxqJyAYdFAjVsJpflCPrtaXtKFN2601T4c0sKYZ3yvvSy3kg9zuP28MUtAWOh+x25T2rjScX0DykFZxli42o/ndBlhPuOolrvwOZgJiR0hzA==; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1RfTJ9-0009Re-7O; Tue, 27 Dec 2011 12:26:55 +0300 Date: Tue, 27 Dec 2011 13:26:51 +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="JVVqWhpkAs5raV7A" Content-Disposition: inline In-Reply-To: <4EF971E4.4050905@FreeBSD.org> <4EF96D7D.3030701@FreeBSD.org> Sender: rea@codelabs.ru Cc: Pyun Yong-Hyeon , Brooks Davis , freebsd-rc@FreeBSD.ORG, Garrett Cooper , Gleb Smirnoff , Dag-Erling Smorgrav , d@delphij.net, Xin LI 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: Tue, 27 Dec 2011 09:26:58 -0000 --JVVqWhpkAs5raV7A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Mon, Dec 26, 2011 at 11:21:08PM -0800, Doug Barton wrote: > On 12/26/2011 22:39, Eygene Ryabinkin wrote: > > This solution will also do the work, but I am slightly concerned > > that it will > >=20 > > - call all netif machinery for interfaces with static IPs: >=20 > The machinery is not that big/complex. It is not an argument. It would be an argument, if this addition will add the substantial value, so putting the load on the system via the added netif invocation will worth it. > > it will be useless for already-configured interfaces; >=20 > It also won't harm anything. It just ruined the connectivity of my workstation I am sitting in front of. I had just changed the devd rule to {{{ notify 0 { match "system" "IFNET"; match "type" "LINK_UP"; media-type "ethernet"; action "/etc/rc.d/netif quietstart $subsystem"; action "logger /etc/rc.d/netif quietstart $subsystem"; }; }}} And I had started to experience infinite link flaps on my static interface: {{{ Dec 27 11:51:59 rea: /etc/rc.d/netif quietstart msk0 Dec 27 11:52:02 rea: /etc/rc.d/netif quietstart msk0 Dec 27 11:52:02 kernel: msk0: link state changed to UP Dec 27 11:52:02 kernel: msk0: link state changed to DOWN Dec 27 11:52:06 rea: /etc/rc.d/netif quietstart msk0 Dec 27 11:52:06 kernel: msk0: link state changed to UP Dec 27 11:52:06 kernel: msk0: link state changed to DOWN Dec 27 11:52:09 rea: /etc/rc.d/netif quietstart msk0 Dec 27 11:52:09 kernel: msk0: link state changed to UP Dec 27 11:52:09 kernel: msk0: link state changed to DOWN Dec 27 11:52:13 rea: /etc/rc.d/netif quietstart msk0 Dec 27 11:52:13 kernel: msk0: link state changed to UP Dec 27 11:52:13 kernel: msk0: link state changed to DOWN Dec 27 11:52:18 rea: /etc/rc.d/netif quietstart msk0 Dec 27 11:52:18 kernel: msk0: link state changed to UP Dec 27 11:52:18 kernel: msk0: link state changed to DOWN Dec 27 11:52:21 rea: /etc/rc.d/netif quietstart msk0 Dec 27 11:52:21 kernel: msk0: link state changed to UP Dec 27 11:52:21 kernel: msk0: link state changed to DOWN Dec 27 11:52:25 rea: /etc/rc.d/netif quietstart msk0 Dec 27 11:52:25 kernel: msk0: link state changed to UP Dec 27 11:52:25 kernel: msk0: link state changed to DOWN Dec 27 11:52:28 rea: /etc/rc.d/netif quietstart msk0 Dec 27 11:52:28 kernel: msk0: link state changed to UP Dec 27 11:52:28 kernel: msk0: link state changed to DOWN Dec 27 11:52:32 rea: /etc/rc.d/netif quietstart msk0 Dec 27 11:52:32 kernel: msk0: link state changed to UP Dec 27 11:52:32 kernel: msk0: link state changed to DOWN }}} This is with devd running. With devd disabled and running 'service netif quietstart msk0' I had discovered the reason: 'start' for msk(4) makes interface to be brought down and resurrected back (the logs are from two invocations of netif to assure myself that the problem is repeatable): {{{ Dec 27 12:31:27 kernel: msk0: link state changed to DOWN Dec 27 12:31:31 kernel: msk0: link state changed to UP Dec 27 12:31:35 kernel: msk0: link state changed to DOWN Dec 27 12:31:38 kernel: msk0: link state changed to UP }}} So, in my case, linkup event triggers devd and 'netif start' that, in turn, triggers DOWN/UP, so we have while(1)-type loop. This isn't "won't harm anything"-type of change, isn't it? > > - in the case of vlan interfaces, ifconfig dance will be done twice > > for each of them: once from the netif for the parent interface and > > once for each vlan in turn. >=20 > Are you certain that the devd.conf trigger will fire when a vlan is up'ed? Doug, please, do everyone a favor: if you're unsure in something, check it by yourself first. This will greatly reduce the number of such questions. It is all simple: add variable 'vlans_' to rc.conf and set its value to some numbers, say '1 2'. Then add 'ifconfig__1' and 'ifconfig__2' saying, for example, 'up'. Run 'service netif start', unplug the cable and watch the logs for UP/DOWN interface notifications. Here are mine with 2 VLANs: {{{ Dec 27 09:43:57 kernel: sk0: link state changed to DOWN Dec 27 09:43:57 kernel: sk0.1: link state changed to DOWN Dec 27 09:43:57 kernel: sk0.2: link state changed to DOWN Dec 27 09:44:00 kernel: sk0: link state changed to UP Dec 27 09:44:00 kernel: sk0.1: link state changed to UP Dec 27 09:44:00 kernel: sk0.2: link state changed to UP }}} > > This will just do the work that is useless in all-static configuration. >=20 > I'm not sure I agree that it's useless. I can actually see this as quite > handy. Personally I try to be in the habit of adding the configuration > to rc.conf first, and using netif to start the interface so that I know > for sure what will happen when that host reboots. No problems, do it yourself by hand. But we're talking about devd who will do this automatically upon the link flap event. That's useless and, as was demonstrated by me and Garrett, harmful. > > Worse, this solution will ruin host's connectivity in the following > > scenario: > >=20 > > - one runs his remote server with all static configuration and strict, > > default-to-deny firewall configuration (call this person "Eygene > > Ryabinkin"); > >=20 > > - his upstream provider tells him: listen, we're rearranging our IP > > space and you should change IP1 to IP2; > >=20 > > - administrator is busy changing the configuration of his host; his > > plan is to substitute IP1 to IP2 everywhere and to reboot his > > machine to cleanly acquire IP2 and continue operations; > >=20 > > - he already substituted IP1 -> IP2 in rc.conf and starts poking > > the firewall configuration, but here comes the link down event > > due to the $PROVIDER who reconfigures his $CISCO or whatever; > >=20 > > - the system ends up in an unusable state, because link up event > > will change interface's IP, but firewall isn't ready for this > > and isn't allowing connections to IP2, but allows them only for > > IP1 that is already gone from the interface due to devd and netif > > script. >=20 > First, I think what you're describing is a pretty small edge case. Doug, I am sorry, but that's childish: no matter how small is the probability, this event _will_ happen. And it will make the administrator in question to lose the connectivity of his server: that's not just "I will lose the message to the log". He will scratch his head, because it is very unnatural thing in the all-static configuration. Once he will find what happened, he won't be satisfied with the way FreeBSD works in this area, I promise. That's not a feature, that's a bug. Once again, you're trying to tell me: my solution is better, but yes, it will horribly fail in the minority of cases up to rendering the remote system unusable in a very unnatural way that can't be predicted =66rom the common sense, but requires the administrator to know deeply the internals of how devd.conf is currently organized. All I can answer, that such a solution (if I am correct and it will fail in such a way) is a no go at all, unless $SOMETHING will be fixed to cure the problems. > > People may tell me that > >=20 > > - Eygene Ryabinkin should run firewall configuration whose knowledge > > of IP for the interface is based on the automagic like ipfw's "me" > > verb; > >=20 > > - Eygene Ryabinkin should not work with the remote host without access > > to its physical console via remote KVM or alike; >=20 > Second, these are both valid points. :) The first one is, actually, can't be implemented in the general case when the interface runs many IPs and I require different firewalling rules for different IPs: ipfw's "me" catches _all_ IPs in the system and if there will be some macro of sort "addrs()", it will catch all IPs of the given interface, at best. pf's '()' works only at the ruleset load time, so its's not dynamic at all. > > I am aware of these fine points, however my meat is that static IP > > configuration is the _static_ one (cool assertion, isn't it?). But it > > has at least one consequence: people view their static IP > > configurations as a really static ones and tend to think that only their > > direct actions will change them. So, any non-atomic changes in > > configuration won't be regarded as a problem: only direct actions that > > will initiate the reconfiguration of the network interfaces must > > change the stuff and changes in configuration files that aren't > > supplemented with such actions must not change anything. >=20 > I agree that this change will require user education. It shouldn't, because it has no real gain apart from fixing the DHCP issue in the way that is different from mine, even if the solution will be 100% harmless. And it isn't harmless, that's the problem. > However 'ifconfig down' and 'ifconfig up' are actually direct > actions. What are you trying to say by this? When firewall is involved, it is not just 'ifconfig down', 'ifconfig up', it will require at least 'service ipfw/pf/ipf restart' and 'service routing restart'. > Users who don't want this can simply comment out the entry > in rc.conf, or the entry in devd.conf. Users that want netif in their devd.conf instead of dhclient can change the devd.conf by themselves. And, given that your change - makes some interfaces to enter the infinite up/down flapping; - makes default route to disappear; it should be written in bold in devd.conf: "don't stick netif here, unless you want these 'side effects'". > > Your way to fix the problem adds the possibility of the > > linkdown/linkup event combo to alter the configuration that is in the > > process of being changed. That's unexpected and one can't be ready > > for it in all situations (though remote console will save some brain > > cells): it depends on the external factor one can't fully control. >=20 > In very rare edge cases, yes. Damn, rather big part of my work consists of these edge cases, when two "unlikely" factors came into the existence and systems are behaving in an "improbable" way. Doug, OS and its infrastructure must be reliable and work with POLA in mind. > > Linkup/linkdown events aren't that rare and generally they are not > > viewed as something unusual that will ruin people's connectivity: > > as long as L3 layer and above will stay alive, link flaps on L2 > > shouldn't change its operations apart from outages for the flap > > duration. >=20 > But it's the combination of "unexpected L2 flap" AND "being in the > process of making an rc.conf change" that will trigger the problem > you describe. And once again, if the user doesn't want the change to > take effect immediately they can comment it out. If no config exists > for the interface, nothing bad will happen. Had you heard about Fukishima power plant? > > So, my motto here is "Static is static, leave it alone and don't > > make it to depend on the dynamic events; DHCP is the dynamic > > protocol by its nature, so it can depend on the dynamic events". >=20 > While I don't agree that the problems you're describing are enough > of a possibility to be concerned about, the other alternative that I > considered is for devd.conf to call a wrapper script that first > determines whether or not it's a DHCP interface, and then calls > rc.d/dhclient if it is. However, there are a couple of downsides to > that. First, it's more work. :) But seriously, one advantage of > using netif is that it will also work with interfaces that are > dynamically configured with IPv6. If we were to move to a wrapper > script idea I'd like to see it support that as well as IPv4 DHCP. This wrapper script will either duplicate the internals of dhclient and whatever machinery for IPv6 in the part of determining the applicability of the dynamical configuration for this interface or it will blindly call dhclient and other scripts checking if they were successful or not. I would not be against the netif route, but it creates serious problems with a) unnatural behaviour of the network stack in the "edge" cases; b) constant link flapping for at least msk(4) interfaces; c) default routes (essentially, all routes that go through the interface in question): they just disappear, at least for the msk(4), sk(4) and nfe(4) interfaces. The demo will be provided in my reply to your message with ID 4EF96D7D.3030701@FreeBSD.org. On the other hand, documenting the "quiet" semantics and using it for dhclient to silence the error will - fix the issue; - allow wrapper script you're talking about to be written in a simple way without duplicating the machinery inside dhclient. --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --JVVqWhpkAs5raV7A Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iF4EAREIAAYFAk75j1sACgkQFq+eroFS7PsJrAEAjjHsVae7/3xuker+gQCsRbyw 9D5nTYg/NS0Jvbq1sbIA/jYCjlVyz7NOuForzDa8JW5w11R3aN/Sfzi90dQ66+X7 =eOVp -----END PGP SIGNATURE----- --JVVqWhpkAs5raV7A-- From owner-freebsd-rc@FreeBSD.ORG Tue Dec 27 09:59:57 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 23195106566C; Tue, 27 Dec 2011 09:59:57 +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 A5CE88FC12; Tue, 27 Dec 2011 09:59:56 +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:References:Message-ID:Subject:Cc:To:From:Date; bh=cL4FsuoX96rSmSXNIy1jJWvVlyATv0P+6aHeZm78c8o=; b=fOJczQZS8RSfPAhR6UcFHK/kvA7i6y4z56ZWdQCzZ2k3iqMZ7Y0VSLRXTKrqzlk/UDLZ1bfjruAiOeMPlrfgAyNKwqwK/TDSG4v+Ab3nFDQ0bwASStgBFNHsQQxiJ2EqwvkvMoNe2Knttlzg7NTwUPXARxnlZEKnPp30KxJEnW5qcc143CZor1+Zii44xJKD0YNof4rAg0PSyyf1qzGjbffoGFagOZv3dWsflk23IF9+BZvBAOuw4+CPDd96XcR3J9Rlw/Ui0Wp1z1yaY+PhrW9CHklfsFnG+3Bs8vKrAVoe6yIgG0hsNs17Y7xzZ8xHBT3g61PRs1ZM2StoIkGBRg==; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1RfTp4-000CEq-TO; Tue, 27 Dec 2011 12:59:55 +0300 Date: Tue, 27 Dec 2011 13:59:51 +0400 From: Eygene Ryabinkin To: Doug Barton Message-ID: References: <4EB6693F.2020102@delphij.net> <4EF93429.4020404@FreeBSD.org> <4EF96D7D.3030701@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0ywUhQCikZ2Y3PNw" Content-Disposition: inline In-Reply-To: <4EF96D7D.3030701@FreeBSD.org> Sender: rea@codelabs.ru Cc: Brooks Davis , freebsd-rc@FreeBSD.ORG, Garrett Cooper , Dag-Erling Smorgrav , d@delphij.net, Xin LI 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: Tue, 27 Dec 2011 09:59:57 -0000 --0ywUhQCikZ2Y3PNw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Mon, Dec 26, 2011 at 11:02:21PM -0800, Doug Barton wrote: > On 12/26/2011 22:31, Garrett Cooper wrote: > > The only misgiving that I have about this is that it deletes the > > default route >=20 > Um, I'm not sure how it would do that. Can you fill me in? I can: {{{ # ifconfig nfe0 nfe0: flags=3D8802 metric 0 mtu 1500 options=3D82008 ether 00:18:f3:97:38:85 media: Ethernet autoselect (none) status: no carrier # ifconfig nfe0 inet 10.0.0.1 # route add -host 144.206.1.1 10.0.0.1 add host 144.206.1.1: gateway 10.0.0.1 # netstat -rn | grep 144.206.1.1 144.206.1.1 10.0.0.1 UHS 0 0 nfe0 # ifconfig nfe0 inet 10.0.0.1 # netstat -rn | grep 144.206.1.1 }}} and for interface in UP state {{{ $ ifconfig sk0 sk0: flags=3D8843 metric 0 mtu 1500 options=3D80009 ether 00:22:15:6e:9d:a9 inet 10.0.0.2 netmask 0xffffff00 broadcast 10.0.0.255 media: Ethernet autoselect (1000baseT ) status: active $ netstat -rn | grep 10.0.0.2 10.0.0.2 link#10 UHS 0 0 lo0 $ route add -host 144.206.1.1 10.0.0.2 add host 144.206.1.1: gateway 10.0.0.2 $ netstat -rn | grep 144.206.1.1 144.206.1.1 10.0.0.2 UHS 0 0 sk0 $ ifconfig sk0 inet 10.0.0.2/24 $ netstat -rn | grep 144.206.1.1 }}} All routes that are going through the interface are deleted from the routing table when we are assigning the address to the interface (not the alias, but the primary address). That happens because ifconfig's setifaddr() routine sets clearaddr to 1, http://svnweb.freebsd.org/base/head/sbin/ifconfig/ifconfig.c?revision=3D2= 28571&view=3Dmarkup#l636 ifconfig's ifconfig() function calls ioctl(SIOCDIFADDR) when clearaddr is non-zero, http://svnweb.freebsd.org/base/head/sbin/ifconfig/ifconfig.c?revision=3D2= 28571&view=3Dmarkup#l607 and SIOCDIFADDR scrubs the interface routes, http://svnweb.freebsd.org/base/head/sys/netinet/in.c?revision=3D228768&vi= ew=3Dmarkup#l601 for the natural reasons: we're deleting the interface address here. May I ask, if you tried to use the lone 'service netif start ' on your machine with all-static IP configuration and default route sitting on and what were the results of the test in respect to the state of the routing table and generall connectivity of your machine to the external networks after this test? Or, may be, you just tried your solution on the DHCP-enabled interface only? --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --0ywUhQCikZ2Y3PNw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iF4EAREIAAYFAk75lxcACgkQFq+eroFS7PvxMgD9GhM9ekMLhgE7rHGZaXkXIoKq OpxdIlcK5mEt9/zME9wA/iJBUFAvX5CfMALfbICPbrkFRJ2Ol73reIhGstwTAhKo =4Kz4 -----END PGP SIGNATURE----- --0ywUhQCikZ2Y3PNw-- From owner-freebsd-rc@FreeBSD.ORG Tue Dec 27 10:28:18 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 BD6011065672; Tue, 27 Dec 2011 10:28:18 +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 0B43714EF3C; Tue, 27 Dec 2011 10:28:12 +0000 (UTC) Message-ID: <4EF99DBC.6020204@FreeBSD.org> Date: Tue, 27 Dec 2011 02:28:12 -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: 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 , Brooks Davis , freebsd-rc@FreeBSD.ORG, Garrett Cooper , Gleb Smirnoff , Dag-Erling Smorgrav , d@delphij.net, Xin LI 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: Tue, 27 Dec 2011 10:28:18 -0000 On 12/27/2011 01:26, Eygene Ryabinkin wrote: > I would not be against the netif route, but it creates serious > problems Ok, you've convinced me that this approach isn't viable. That's why I asked for review before committing it. Thanks for looking at it in more detail. I will take a stab at the idea of a wrapper script tomorrow. It's not going to need to duplicate anything more of the mechanics of rc.d/dhclient than calling dhcpif(), which is itself from network.subr, so the code duplication is extremely minimal. If nothing else, the ability to add configuration of IPv6 interfaces here would make it worthwhile. Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-rc@FreeBSD.ORG Tue Dec 27 15:29:04 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 D45BD106566C; Tue, 27 Dec 2011 15:29:04 +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 5B3798FC13; Tue, 27 Dec 2011 15:29:04 +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:References:Message-ID:Subject:Cc:To:From:Date; bh=QgRHBR5iPFquRJo0Sd81m3ZWCHAxuJfAISZB9XUDscQ=; b=l/6eQC0krROiooALsjLp5k4BRkmOQYLbdnX0LtLuIqulJ3zyTw0VU4rA6CoxevWO/feEPAFekdarbaGPJadMfBJZxX8CF3jouaJKDHEigBz+XcmGg01mxIBrXjaQyhO0SaOBWEs8Z30/PCmizJjhroBH3HLuj1OqTeM2Z1m2b20MRfAitRhPVXJ+gUeYkTSqhYA1HTHiNTZHtF18xcrnIYqjHuz9Mx4XIY1x7W0ozYZdMOkgTtkVtvwLJgcjFpSs0y92IgikRYsgddUp9v+nxsKFn63o81ozF9AAkXVe+2LO+xK0Aog5Tk9Lzh3+WWdP4eUDsVKa/HdkpKw+p5FjnQ==; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1RfYxa-000E0m-DL; Tue, 27 Dec 2011 18:29:02 +0300 Date: Tue, 27 Dec 2011 19:28:56 +0400 From: Eygene Ryabinkin To: Doug Barton Message-ID: References: <4EF99DBC.6020204@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="309evMHi/619oHyA" Content-Disposition: inline In-Reply-To: <4EF99DBC.6020204@FreeBSD.org> Sender: rea@codelabs.ru Cc: Pyun Yong-Hyeon , Brooks Davis , freebsd-rc@FreeBSD.ORG, Garrett Cooper , Gleb Smirnoff , Dag-Erling Smorgrav , d@delphij.net, Xin LI 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: Tue, 27 Dec 2011 15:29:05 -0000 --309evMHi/619oHyA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Tue, Dec 27, 2011 at 02:28:12AM -0800, Doug Barton wrote: > On 12/27/2011 01:26, Eygene Ryabinkin wrote: > > I would not be against the netif route, but it creates serious > > problems >=20 > Ok, you've convinced me that this approach isn't viable. How cool is that ;)) > That's why I asked for review before committing it. Thanks for > looking at it in more detail. You are welcome. > I will take a stab at the idea of a wrapper script tomorrow. It's not > going to need to duplicate anything more of the mechanics of > rc.d/dhclient than calling dhcpif(), which is itself from network.subr, > so the code duplication is extremely minimal. If nothing else, the > ability to add configuration of IPv6 interfaces here would make it > worthwhile. I have no problems with the wrapper if it will do some additional tasks, but just one question: if we will omit the IPv6 stuff for a while, how your wrapper will be different from my approach of using the 'quietstart' keyword? Your wrapper will determine that DHCP isn't enabled on the interface and will call 'service dhclient quietstart $ifn'. My 'quietstart' patch already embeds the part of your wrapper that uses dhcpif and will bail out quickly. The general logics for your wrapper (the full one, with IPv6 autoconf) will likely look as the following: {{{ start () { service dhclient quietstart $ifn && exit 0 quietstart $ifn && exit 0 exit 1 } }}} One could conditionalize the priority of DHCP and IPv6 given that the dhclient from base will support IPv6 at some point (just now it doesn't support, at least I hadn't found any IPv6 bits inside /usr/src/sbin/dhclient in -CURRENT), but that's another story that is out of the current scope. Your wrapper, that won't exploit my patch, will look like {{{ start () { dhcpif $ifn && \ service dhclient quietstart $ifn && exit 0 ipv6_autoconfif $1 && \ quietstart $ifn && exit 0 exit 1 } }}} I just wonder why you're not up to using the existing 'quietstart' semantics? Our conversation 'bout it stopped at the point of the message http://lists.freebsd.org/pipermail/freebsd-rc/2011-December/002587.html It will be still good to know what worries you in my approach. Could you, please, answer to the first part of my message about the failure you're concerned with? Thanks. --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --309evMHi/619oHyA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iF4EAREIAAYFAk755DgACgkQFq+eroFS7Ps2fwEAhspur+C4DZa4JexXmVY2KsPT kdg72HkUY2756aRmsV0A/R10lImzEEh0Ecs4RCJ1+slBV38LQdCT9/PZ3x9582+W =1Ikv -----END PGP SIGNATURE----- --309evMHi/619oHyA-- 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? From owner-freebsd-rc@FreeBSD.ORG Tue Dec 27 18:20:12 2011 Return-Path: Delivered-To: freebsd-rc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55C69106566C for ; Tue, 27 Dec 2011 18:20:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 42A4D8FC0A for ; Tue, 27 Dec 2011 18:20:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pBRIKCqp084960 for ; Tue, 27 Dec 2011 18:20:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pBRIKCKB084959; Tue, 27 Dec 2011 18:20:12 GMT (envelope-from gnats) Date: Tue, 27 Dec 2011 18:20:12 GMT Message-Id: <201112271820.pBRIKCKB084959@freefall.freebsd.org> To: freebsd-rc@FreeBSD.org From: Devin Teske Cc: 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 Reply-To: Devin Teske 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:20:12 -0000 The following reply was made to PR conf/163508; it has been noted by GNATS. From: Devin Teske To: , Cc: Subject: Re: conf/163508: [rc.subr] [patch] Add "enable" and "disable" commands to rc.subr Date: Tue, 27 Dec 2011 10:17:42 -0800 ------=_NextPart_000_0285_01CCC480.C5B42FC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I would like to submit for review a modified version of the original submitter's patch. I feel that the original patch takes a too-simplistic view of the problem at-hand and am offering a much more robust solution. The replacement patch uses my "sysrc" utility which -- if you haven't discovered it yet -- is a peer-reviewed "nuclear reactor" approach opposed to a "bike shed" approach. sysrc takes everything into consideration, including (but not limited to): (listed in no particular order) 1. Environment Variable Taint It is not possible to "confuse" or "break" the code by exporting strange things into the environment. 2. Shell Taint Checking If rc.conf(5) has invalid syntax prior to editing, it will refuse to edit and an error is produced. Similarly, if editing rc.conf(5) introduces a syntax error, the original rc.conf(5) is restored and an error is produced. This prevents producing a situation where rc.conf itself prevents you from booting into multi-user mode. If, for any reason at all, rc.conf(5) causes you to drop to single-user mode, it's assuredly is NOT because of sysrc, as it taint-checks both before and after. 3. Safety First Use mktemp to prevent race-conditions. Use atomic actions where necessary. 4. Minimal changes The original patch submitted with conf/163508 does more work than is necessary w/respect to items-changed within a single-file. Case-in-point, the "replace_var" function simply fires a sed global-replace to replace all instances of "thing=blah" on multiple lines. That's not cool. Sysrc will ONLY change the last [valid] assignment to the variable. Sysrc wants to keep your rc.conf exactly the way you like it as best it can and change as little as possible (and when it does make changes, it wants to do it in a fashion that's going to preserve as much structure as possible; see next item). 5. Quotations, whitespace, compound statements and in-line comments The sed command in the original patch's "replace_var" function (a) WILL preserve leading whitespace but (b) WON'T preserve in-line comments that appear after the assignment, (c) NOR preserve the type of quotation that was used in the assignment(s), (d) NOR preserve compound statements. When sysrc replaces the last [valid] assignment to a given variable, it will actually preserve the type of quotation used (whether it be single, double or no-quotation). It will also preserve both leading whitespace and trailing whitespace. It will also retain in-line comments. It will also preserve trailing commands in a compound statement (multi-variable-assignment compound separated by whitespace or multi-command compound separated by semi-colon). 6. Leave certain things alone! Sysrc will refuse to modify things that it knows that it couldn't have possibly done. For example, it will refuse to touch something like this: foogribble_enable=`echo YES` and instead opt to add an overriding new entry. 7. Performance Sysrc has been rewritten several times to improve performance. It heavily leverages awk to improve performance by several orders of magnitude compared to using straight bourne-shell built-in internals. ( end itemized list ; continue discussion ) The above list calls out major flaws in the currently-submitted patch and highlights the fact that sysrc has no such short-comings. NOTE: sysrc would have to be taken into the base to support this patch. (aside) MidnightBSD has taken it into its base already (and there's another distro that escapes my mind at the moment, which has similarly taken it into its base) NOTE: In my submitted patch, there are two open-ended questions to reviewers: (a) ought we to use a full pathname to sysrc and if-so (b) where might sysrc be placed? (/bin would be nice so that it's available in single-user mode). -- Devin P.S. sysrc is available here: http://druidbsd.sourceforge.net/download/sysrc.txt _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ------=_NextPart_000_0285_01CCC480.C5B42FC0 Content-Type: text/plain; name="conf_163508_patch.new.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="conf_163508_patch.new.txt" --- /usr/src.8/etc/rc.subr 2011-09-25 10:25:06.000000000 +0300=0A= +++ /etc/rc.subr 2011-12-27 08:33:50.000000000 -0800=0A= @@ -443,7 +443,7 @@=0A= #=0A= # run_rc_command argument=0A= # Search for argument in the list of supported commands, which is:=0A= -# "start stop restart rcvar status poll ${extra_commands}"=0A= +# "start stop restart rcvar status poll enable disable = ${extra_commands}"=0A= # If there's a match, run ${argument}_cmd or the default method=0A= # (see below).=0A= #=0A= @@ -579,6 +579,10 @@=0A= #=0A= # rcvar Display what rc.conf variable is used (if any).=0A= #=0A= +# enable Set ${rcvar} to YES=0A= +#=0A= +# disable Set ${rcvar} to NO=0A= +#=0A= # Variables available to methods, and after run_rc_command() has=0A= # completed:=0A= #=0A= @@ -647,7 +651,7 @@=0A= eval _override_command=3D\$${name}_program=0A= command=3D${_override_command:-$command}=0A= =0A= - _keywords=3D"start stop restart rcvar $extra_commands"=0A= + _keywords=3D"start stop restart rcvar enable disable $extra_commands"=0A= rc_pid=3D=0A= _pidcmd=3D=0A= _procname=3D${procname:-${command}}=0A= @@ -689,12 +693,26 @@=0A= if [ "$_elem" !=3D "$rc_arg" ]; then=0A= continue=0A= fi=0A= +=0A= + if [ -n "${rcvar}" -a "${rc_arg}" =3D=3D "enable" ]; then=0A= + if checkyesno ${rcvar}; then=0A= + echo "Service ${name} already enabled."=0A= + return 0=0A= + fi=0A= + fi=0A= + if [ -n "${rcvar}" -a "${rc_arg}" =3D=3D "disable" ]; then=0A= + if ! checkyesno ${rcvar}; then=0A= + echo "Service ${name} not enabled."=0A= + return 0=0A= + fi=0A= + fi=0A= +=0A= # if ${rcvar} is set, $1 is not "rcvar"=0A= # and ${rc_pid} is not set, then run=0A= # checkyesno ${rcvar}=0A= # and return if that failed=0A= #=0A= - if [ -n "${rcvar}" -a "$rc_arg" !=3D "rcvar" -a "$rc_arg" !=3D "stop" = ] ||=0A= + if [ -n "${rcvar}" -a "$rc_arg" !=3D "rcvar" -a "$rc_arg" !=3D "stop" = -a "$rc_arg" !=3D "enable" ] ||=0A= [ -n "${rcvar}" -a "$rc_arg" =3D "stop" -a -z "${rc_pid}" ]; then=0A= if ! checkyesno ${rcvar}; then=0A= if [ -n "${rc_quiet}" ]; then=0A= @@ -895,6 +913,16 @@=0A= echo ""=0A= ;;=0A= =0A= + enable|disable)=0A= + local val=0A= + if [ "$rc_arg" =3D "enable" ]; then=0A= + val=3D"YES"=0A= + else=0A= + val=3D"NO"=0A= + fi=0A= + sysrc "$rcvar=3D$val" && sysrc -v "$rcvar"=0A= + ;;=0A= +=0A= *)=0A= rc_usage $_keywords=0A= ;;=0A= ------=_NextPart_000_0285_01CCC480.C5B42FC0-- From owner-freebsd-rc@FreeBSD.ORG Tue Dec 27 19:54:26 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 ABFC1106566C; Tue, 27 Dec 2011 19:54:26 +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 A006B154DCA; Tue, 27 Dec 2011 19:54:24 +0000 (UTC) Message-ID: <4EFA2270.4060107@FreeBSD.org> Date: Tue, 27 Dec 2011 11:54:24 -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: freebsd-rc@FreeBSD.org References: <4EFA21E7.1070006@FreeBSD.org> In-Reply-To: <4EFA21E7.1070006@FreeBSD.org> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 X-Forwarded-Message-Id: <4EFA21E7.1070006@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Eygene Ryabinkin 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: Tue, 27 Dec 2011 19:54:26 -0000 Ok, you win, I give up. Do whatever you think is right. Good luck, Doug From owner-freebsd-rc@FreeBSD.ORG Tue Dec 27 19:44:48 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 7D2BD106566C; Tue, 27 Dec 2011 19:44:48 +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 0D6C08FC13; Tue, 27 Dec 2011 19:44:47 +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:References:Message-ID:Subject:Cc:To:From:Date; bh=786jwvtJ2vYVzRQEeGCLptroDlZ2gzx3Aboq2ExkpoE=; b=AWtbt/Yovmgt4tCUufTNxSQ2FoNc0V+ZZz6yfimKUPrBli7Drm6dNujzMKvA796x+1ipZo5F673YvHwG7KGwcHjtYJtweOQkxNdwKBy9QU2vCW9Od5sAz3m4HyKew1Oqc42jInHFIyaVWdmV+A4wCN/5cM7ujr1/pl95dxjOOXvkaZlSAyiCirM6Cu/rDw38LNDo9GMLLZrHmUY+A69KmPqbWYxZvn/29LtPebX4h1uGl7aqETSzoxNJ/7iRwyg/PpVaeGWCJzL5aGPuFMwR5pe91r7MQQy6pTEK7iFFEHiKUkhCG7H2Q3tKC0z7jpBSwgXpaJo759s+ECdIS3+dtw==; Received: from shadow.codelabs.ru (ppp91-77-186-141.pppoe.mtu-net.ru [91.77.186.141]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1Rfcx4-000A7N-GK; Tue, 27 Dec 2011 22:44:46 +0300 Date: Tue, 27 Dec 2011 23:44:40 +0400 From: Eygene Ryabinkin To: Doug Barton , bz@freebsd.org Message-ID: References: <4EF99DBC.6020204@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline In-Reply-To: <4EF99DBC.6020204@FreeBSD.org> Sender: rea@codelabs.ru X-Mailman-Approved-At: Tue, 27 Dec 2011 19:58:25 +0000 Cc: Pyun Yong-Hyeon , Brooks Davis , freebsd-rc@FreeBSD.ORG, Garrett Cooper , Gleb Smirnoff , Dag-Erling Smorgrav , d@delphij.net, Xin LI 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: Tue, 27 Dec 2011 19:44:48 -0000 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Note for Bjoern: you can skip some parts of this mail, the real question is near the bottom of the letter. In a nutshell, Doug wants to arm the devd machinery that looks for IFUP events to do IPv6 autoconfiguration as addition to the current invocation of a DHCP client, but I have some questions about IPv6 autoconfiguration that I can't answer myself. Tue, Dec 27, 2011 at 02:28:12AM -0800, Doug Barton wrote: > Ok, you've convinced me that this approach isn't viable. That's why > I asked for review before committing it. Thanks for looking at it in > more detail. By the way, it seems that your approach won't work at all for DHCP-enabled interfaces that aren't set to the synchronous DHCP mode (rc.conf knob synchronous_dhclient, default value is "NO"): netif has the following code: {{{ if dhcpif $1; then if [ $_cfg -ne 0 ] ; then ifconfig $1 up fi if syncdhcpif $1; then /etc/rc.d/dhclient start $1 fi _cfg=3D0 fi }}} So, it relies on the devd to invoke dhclient when interface will be up and configured. I imagine that its mostly for the WiFi interfaces that should associate themselves with the AP or other host, up the encryption and do other stuff that takes time. DHCP client should start only after these negotiations will be complete and the link will really be up. Thus, DHCP-enabled interfaces should react to the linkup events by anything that ends up calling dhclient, not netif. I was just thinking of how can one implement the wrapper script for doing DHCP and IPv6 autoconfiguration that you want to implement and my initial thoughts were that we can use a simple one-shot invocation of netif {{{ if dhcpif $ifn || ipv6_autoconfif $ifn; then service netif quietstart $ifn fi }}} but this won't work for DHCP. On the topic of IPv6 autoconfiguration. The need of restart of the DHCP client upon linkdown/linkup event is simple: dhclient uses bpf(4) and it dies when link goes down. So it needs to be restarted. Since I have no IPv6 machines to test on and IPv6 will (hopefully) come to my realm only next year, I can't test my assertions 'bout it, since I have no practical experience with it. Thus I can be wrong in all my IPv6-related sayings. =46rom the other hand, reading RFC 2462, ftp://ftp.ripe.net/rfc/rfc2462.txt and crawling over the ifconfig, netif and other stuff, I have a strong impression that interface flags AUTO_LINKLOCAL and ACCEPT_RTADV (that, respectively, judge if the link local address should be automatically generated and if router advertisments should be processed) are persistent in respect to the link flaps. Moreover, manual page for rtsold(8) says {{{ o The interface is up after a temporary interface failure. rtsold detects such failures by periodically probing to see if the status= of the interface is active or not. Note that some network cards and drivers do not allow the extraction of link state. In such cases, rtsold cannot detect the change of the interface status. }}} so the thing that generates router solicitations is more-or-less persistent and doesn't die on link down events. Thus, it may be well so that only the initial linkup event is the one that will really initiate IPv6 autoconfiguration and all other linkup events won't really need such a processing. I am CC'ing bz@freebsd.org, since he is the person who is known to mess with IPv6 in FreeBSD a lot. Bjoern, could you, please, say if IPv6-autoconfigured interfaces react to the linkdown/linkup events in a way that they will require some reconfiguration after the flap to autoconfigure themselves again. Of course, if there are other IPv6 wizards nearby, they are welcome to educate me on this topic. Thanks. --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iF4EAREIAAYFAk76ICgACgkQFq+eroFS7PuIOAD5ATJCFsboqq1paiuJnZ9WvKtL 1eP2UlYQnM27wZfb+fcA/Auvta258XTENhNgJdguOelpEAvSk+c0n2ePs9onIY5r =7aZX -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q-- From owner-freebsd-rc@FreeBSD.ORG Wed Dec 28 04:37:46 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 D2AE0106566B; Wed, 28 Dec 2011 04:37:46 +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 D0CDC15660C; Wed, 28 Dec 2011 04:37:45 +0000 (UTC) Message-ID: <4EFA9D19.6050705@FreeBSD.org> Date: Tue, 27 Dec 2011 20:37:45 -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: <4EF99DBC.6020204@FreeBSD.org> <4EFA21E7.1070006@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-rc@FreeBSD.ORG 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: Wed, 28 Dec 2011 04:37:46 -0000 On 12/27/2011 20:34, Eygene Ryabinkin wrote: > Tue, Dec 27, 2011 at 11:52:07AM -0800, Doug Barton wrote: >> Ok, you win, I give up. >> >> Do whatever you think is right. > > I expected another answer, but this one isn't bad either. > > Does that means that I can stick "Approved by: dougb" to the current > variant of the patch? No. It means I'm done with this. I'm sure you won't have any problems finding a src committer to help you out. Good luck, Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-rc@FreeBSD.ORG Wed Dec 28 04:46:16 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 809ED106566C for ; Wed, 28 Dec 2011 04:46:16 +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 06E3C1521CE; Wed, 28 Dec 2011 04:46:15 +0000 (UTC) Message-ID: <4EFA9F17.5050005@FreeBSD.org> Date: Tue, 27 Dec 2011 20:46:15 -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: Devin Teske References: <201112271820.pBRIKCKB084959@freefall.freebsd.org> In-Reply-To: <201112271820.pBRIKCKB084959@freefall.freebsd.org> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Wed, 28 Dec 2011 04:46:16 -0000 I think you'd be much more likely to get more eyes on your work (thinking minimally of sysrc and your post-install config tool) if you submitted them as ports. I'm fairly confident that I've suggested this in the past, if I haven't, my apologies. There are several benefits to this, not the least of which is that people who are interested in having this kind of tool will have easy access to it. This will either a) solve the problem, or b) allow the idea to grow on people sufficiently that it eventually gets adopted more widely. You can start with http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/index.html and if you need help of course asking on freebsd-ports@ is your next step. Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-rc@FreeBSD.ORG Wed Dec 28 04:52:44 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 3C73A106564A; Wed, 28 Dec 2011 04:52:44 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 00E7C8FC13; Wed, 28 Dec 2011 04:52:43 +0000 (UTC) Received: from pps.filterd (ltcfislmsgpa03 [127.0.0.1]) by ltcfislmsgpa03.fnfis.com (8.14.4/8.14.4) with SMTP id pBS4QlOE005134; Tue, 27 Dec 2011 22:52:43 -0600 Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa03.fnfis.com with ESMTP id 11yrk08k8j-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 27 Dec 2011 22:52:43 -0600 Received: from [10.0.0.105] (10.14.152.30) by smtp.fisglobal.com (10.132.206.15) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 27 Dec 2011 22:52:42 -0600 References: <201112271820.pBRIKCKB084959@freefall.freebsd.org> <4EFA9F17.5050005@FreeBSD.org> In-Reply-To: <4EFA9F17.5050005@FreeBSD.org> MIME-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Message-ID: X-Mailer: iPhone Mail (8C148) From: Devin Teske Date: Tue, 27 Dec 2011 20:52:30 -0800 To: Doug Barton X-Originating-IP: [10.14.152.30] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110, 1.0.211, 0.0.0000 definitions=2011-12-27_08:2011-12-27, 2011-12-27, 1970-01-01 signatures=0 Cc: "" 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: Wed, 28 Dec 2011 04:52:44 -0000 On Dec 27, 2011, at 8:46 PM, Doug Barton wrote: > I think you'd be much more likely to get more eyes on your work > (thinking minimally of sysrc and your post-install config tool) if you > submitted them as ports. I'm fairly confident that I've suggested this > in the past, if I haven't, my apologies. >=20 > There are several benefits to this, not the least of which is that > people who are interested in having this kind of tool will have easy > access to it. This will either a) solve the problem, or b) allow the > idea to grow on people sufficiently that it eventually gets adopted more > widely. >=20 > You can start with > http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/index.h= tml > and if you need help of course asking on freebsd-ports@ is your next step. >=20 > Doug Thank you. I'll give it a try (my first port). --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-rc@FreeBSD.ORG Wed Dec 28 05:06:02 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 12FB7106566B; Wed, 28 Dec 2011 05:06:02 +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 ADED48FC12; Wed, 28 Dec 2011 05:06:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codelabs.ru; s=two; h=Sender:Content-Type:MIME-Version:Message-ID:Subject:Cc:To:From:Date; bh=m6FhYif8hTTL5KdPy0g/TcjVl3uMHC1PcWNkTC28Jbg=; b=d/lG/0335DPzQ1EgojbQl7VxlFn+iAtlkG4UbgD7dQs05UfTUWARk6Sl4Td45k4X7XLpWAk2P89dIQgzI/E5qI/oKi9uuOYxqduSMMfq3wujx7kBSlBrOON+sEnOzYZLSBes/yD+UZm9oSWy4ARVqM2GxxyHrpdy+600AYuwGj2QRZ7/vzP2WCFJsT5+EfkHPjnNMTacEtlTiqymtMIpMe2pIIjJIYYZNdyPtFtMAxJ1JkmWZ0nyo8SGVVWXwZTn7R/rxW30crgozmklDiXarJgr8ebNy0Msr6gOcNdUj5co9V7ToCoMX5XL+qnv+3Qc4oeRkZUFsYuMTpgTLVxJuA==; Received: from shadow.codelabs.ru (ppp91-77-174-173.pppoe.mtu-net.ru [91.77.174.173]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1RfliC-0006Kd-DL; Wed, 28 Dec 2011 08:06:00 +0300 Date: Wed, 28 Dec 2011 09:05:58 +0400 From: Eygene Ryabinkin To: freebsd-rc@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="da4uJneut+ArUgXk" Content-Disposition: inline Sender: rea@codelabs.ru Cc: gordon@freebsd.org Subject: Usage of the err() inside rc.d scripts 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: Wed, 28 Dec 2011 05:06:02 -0000 --da4uJneut+ArUgXk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Good day. After analyzing my conversation with Doug Barton about 'return' vs 'exit' in the rc.d script I had found the weak point in my arguments: when rc_fast_and_loose is set, rc.d scripts are directly sourced into the /etc/rc, so any call to 'exit' will interrupt /etc/rc in this case. The function err() from rc.subr does call 'exit' and for -CURRENT I see at least 13 scripts that use err() to signify run-time or configuration errors: {{{ $ grep -r 'err[[:space:]]*[0-9]' . | cut -f 1 -d : | uniq =2E/bluetooth =2E/ipfilter =2E/ipfs =2E/jail =2E/mdconfig =2E/mdconfig2 =2E/named =2E/nfsd =2E/ipmon =2E/routing =2E/netif =2E/accounting =2E/netwait }}} power_profile and dhclient were pruned from the list, because they err() only on the bad usage. Looks like that rc_fast_and_loose isn't used much, because otherwise some machines will go single-user on a certain failures of the above scripts. CURRENTly, no things in /etc use or set rc_fast_and_loose, apart from the /etc/rc.subr itself: it only checks its value inside run_rc_script. rc_fast_and_loose was introduced in http://svnweb.freebsd.org/base/head/etc/rc.subr?revision=3D98186&view=3Dm= arkup {{{ Revision 98186 Thu Jun 13 22:19:42 2002 UTC (9 years, 6 months ago) by gordon File size: 23163 byte(s) Bring this up to date with the latest NetBSD bits. Also add some bits of our own. Submitted by: Mike Makonnen Reviewed by: silence on -current and -hackers }}} but I can't extract any useful bits regarding the need of rc_fast_and_loose from this. So, the question is: what is it good for and how people use it? Thanks. --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --da4uJneut+ArUgXk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iF4EAREIAAYFAk76o7UACgkQFq+eroFS7PtNcwD/fX3GVLlZWt2ZLQ4LoFXkW4P0 xviZvbKZkDlThFQywOUA/2crfXTk2ElMxKILYmtsY5CKuXSYa2zWGg/HCWBJ30va =3WVt -----END PGP SIGNATURE----- --da4uJneut+ArUgXk-- From owner-freebsd-rc@FreeBSD.ORG Wed Dec 28 04:34:40 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 5547A1065670; Wed, 28 Dec 2011 04:34:40 +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 DD7098FC1B; Wed, 28 Dec 2011 04:34:39 +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:References:Message-ID:Subject:Cc:To:From:Date; bh=z2maF0p6cXCthx34laI1E9UunJPo4bHIy1yOLYD+yjE=; b=JDXlGVectGCA8gPM1U2DaXSl1I+k5NBejU4vvD/shQFAbkZk0rfgub25QX2e51nRnO9JV/b3yC1OW4FLo1lJCGSP+hE68e4Ryffjgix1/wtObKE3MmQLmBXQjbwF8CBC8wd3Zf4J6Oz8IBg/1yoHKvlYvHaExxdYliPO0dw2TZvr00rlQgvRdV4Mlfe2fP/zc88yX3tTZQpZbeF+1N7VEkQf9vjqkHV7gs5MJAosrx/iz2Qu5H4d/KqhY2OZOwvArhuCwlUf95pWkjTiudLmSYYpmhpWKdMH88j7byUC7TU1gHIH6hEtAw2nDB2Ckw2sKYoiODE0Uvzsjfc9DkzozA==; Received: from shadow.codelabs.ru (ppp91-77-186-141.pppoe.mtu-net.ru [91.77.186.141]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1RflDp-0003XX-Vz; Wed, 28 Dec 2011 07:34:38 +0300 Date: Wed, 28 Dec 2011 08:34:33 +0400 From: Eygene Ryabinkin To: Doug Barton Message-ID: References: <4EF99DBC.6020204@FreeBSD.org> <4EFA21E7.1070006@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="l76fUT7nc3MelDdI" Content-Disposition: inline In-Reply-To: <4EFA21E7.1070006@FreeBSD.org> Sender: rea@codelabs.ru X-Mailman-Approved-At: Wed, 28 Dec 2011 05:40:57 +0000 Cc: Pyun Yong-Hyeon , Brooks Davis , freebsd-rc@FreeBSD.ORG, Garrett Cooper , Gleb Smirnoff , bz@freebsd.org, Dag-Erling Smorgrav , d@delphij.net, Xin LI 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: Wed, 28 Dec 2011 04:34:40 -0000 --l76fUT7nc3MelDdI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Tue, Dec 27, 2011 at 11:52:07AM -0800, Doug Barton wrote: > Ok, you win, I give up. >=20 > Do whatever you think is right. I expected another answer, but this one isn't bad either. Does that means that I can stick "Approved by: dougb" to the current variant of the patch? Or to the modified variant of it if I will decide to change the wording in rc.subr man page? I am ports committer after all, so I need the approval of some src committer(s) to make changes in the rc.d area. Thank you. --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --l76fUT7nc3MelDdI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iF4EAREIAAYFAk76nFkACgkQFq+eroFS7PvefgD/WyjHkhDLqOZdLDnczD2OofNH NDshZ+9+qUIoFiaNUCkBAJf3+T16XY0T4hLdWw1+lHdkWZSuOBhTeFDXibSWpse5 =hLYs -----END PGP SIGNATURE----- --l76fUT7nc3MelDdI-- From owner-freebsd-rc@FreeBSD.ORG Wed Dec 28 07:00:23 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 08789106566B; Wed, 28 Dec 2011 07:00:22 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 75B6F8FC12; Wed, 28 Dec 2011 07:00:13 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pBS6wjkr034958; Wed, 28 Dec 2011 10:58:45 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pBS6wj6l034957; Wed, 28 Dec 2011 10:58:45 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 28 Dec 2011 10:58:45 +0400 From: Gleb Smirnoff To: Doug Barton Message-ID: <20111228065845.GZ8035@glebius.int.ru> References: <4EB6693F.2020102@delphij.net> <4EF93429.4020404@FreeBSD.org> <4EF971E4.4050905@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4EF971E4.4050905@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Pyun Yong-Hyeon , Brooks Davis , freebsd-rc@FreeBSD.org, Eygene Ryabinkin , Dag-Erling Smorgrav , d@delphij.net, Xin LI 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: Wed, 28 Dec 2011 07:00:23 -0000 On Mon, Dec 26, 2011 at 11:21:08PM -0800, Doug Barton wrote: D> > Worse, this solution will ruin host's connectivity in the following D> > scenario: D> > D> > - one runs his remote server with all static configuration and strict, D> > default-to-deny firewall configuration (call this person "Eygene D> > Ryabinkin"); D> > D> > - his upstream provider tells him: listen, we're rearranging our IP D> > space and you should change IP1 to IP2; D> > D> > - administrator is busy changing the configuration of his host; his D> > plan is to substitute IP1 to IP2 everywhere and to reboot his D> > machine to cleanly acquire IP2 and continue operations; D> > D> > - he already substituted IP1 -> IP2 in rc.conf and starts poking D> > the firewall configuration, but here comes the link down event D> > due to the $PROVIDER who reconfigures his $CISCO or whatever; D> > D> > - the system ends up in an unusable state, because link up event D> > will change interface's IP, but firewall isn't ready for this D> > and isn't allowing connections to IP2, but allows them only for D> > IP1 that is already gone from the interface due to devd and netif D> > script. D> D> First, I think what you're describing is a pretty small edge case. This case makes the suggested change unacceptable. This is a common practice to change things with ifconfig w/o modifing rc.conf, and if things go wrong then call server room personnel and ask to reboot a box. So box ma y have different configuration in rc.conf and on interfaces for a long time. Moreover, even if I got the same IP in rc.conf and on an interface, I don't want any address deletion or assignment on link event. This would be spurious messages for routing daemons. -- Totus tuus, Glebius. From owner-freebsd-rc@FreeBSD.ORG Wed Dec 28 21:04:12 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 A4405106566B; Wed, 28 Dec 2011 21:04:12 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 6918D8FC1A; Wed, 28 Dec 2011 21:04:11 +0000 (UTC) Received: from pps.filterd (ltcfislmsgpa01 [127.0.0.1]) by ltcfislmsgpa01.fnfis.com (8.14.4/8.14.4) with SMTP id pBSKS66v026864; Wed, 28 Dec 2011 15:04:11 -0600 Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa01.fnfis.com with ESMTP id 1208hu0gm5-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Dec 2011 15:04:11 -0600 Received: from dtwin (10.14.152.15) by smtp.fisglobal.com (10.132.206.16) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Dec 2011 15:04:10 -0600 From: Devin Teske To: "'Doug Barton'" References: <201112271820.pBRIKCKB084959@freefall.freebsd.org> <4EFA9F17.5050005@FreeBSD.org> In-Reply-To: <4EFA9F17.5050005@FreeBSD.org> Date: Wed, 28 Dec 2011 13:04:18 -0800 Message-ID: <030a01ccc5a4$443f9db0$ccbed910$@fisglobal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ8+sCpiv/7d0iozMJ3jydxE+0QtAJv4p+clH3TsHA= Content-Language: en-us X-Originating-IP: [10.14.152.15] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110, 1.0.211, 0.0.0000 definitions=2011-12-28_07:2011-12-28, 2011-12-28, 1970-01-01 signatures=0 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: Wed, 28 Dec 2011 21:04:12 -0000 > -----Original Message----- > From: Doug Barton [mailto:dougb@FreeBSD.org] > Sent: Tuesday, December 27, 2011 8:46 PM > To: Devin Teske > Cc: freebsd-rc@FreeBSD.org > Subject: Re: conf/163508: [rc.subr] [patch] Add " enable" and " > disable" commands to rc.subr > > I think you'd be much more likely to get more eyes on your work (thinking > minimally of sysrc and your post-install config tool) if you submitted them as > ports. I'm fairly confident that I've suggested this in the past, if I haven't, my > apologies. > > There are several benefits to this, not the least of which is that people who are > interested in having this kind of tool will have easy access to it. This will either a) > solve the problem, or b) allow the idea to grow on people sufficiently that it > eventually gets adopted more widely. > > You can start with > http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters- > handbook/index.html > and if you need help of course asking on freebsd-ports@ is your next step. > > > Doug I submitted ports/163679 today after: a. Reading the Porter's Handbook front-to-back b. Reading Mk/bsd.port.mk c. Looking at many others' port submissions that are pending Thanks Doug, for pointing me to the Porter's Handbook. Also, thanks for pushing me to do it. It wasn't as hard as I thought it would be. -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-rc@FreeBSD.ORG Wed Dec 28 21:30:17 2011 Return-Path: Delivered-To: freebsd-rc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A7F3106566C for ; Wed, 28 Dec 2011 21:30:17 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 682448FC08 for ; Wed, 28 Dec 2011 21:30:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pBSLUH52033031 for ; Wed, 28 Dec 2011 21:30:17 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pBSLUH37033028; Wed, 28 Dec 2011 21:30:17 GMT (envelope-from gnats) Date: Wed, 28 Dec 2011 21:30:17 GMT Message-Id: <201112282130.pBSLUH37033028@freefall.freebsd.org> To: freebsd-rc@FreeBSD.org From: Devin Teske Cc: 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 Reply-To: Devin Teske 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: Wed, 28 Dec 2011 21:30:17 -0000 The following reply was made to PR conf/163508; it has been noted by GNATS. From: Devin Teske To: , Cc: Subject: Re: conf/163508: [rc.subr] [patch] Add "enable" and "disable" commands to rc.subr Date: Wed, 28 Dec 2011 13:21:38 -0800 I've submitted PR ports/163679 to add sysutils/sysrc to the ports-tree. With any luck, it will become immensely popular and then be migrated into the base -- making my previously-attached "conf_163508_patch.new.txt" possible (as it relies on sysrc being available). -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-rc@FreeBSD.ORG Fri Dec 30 10:19:11 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 719991065676; Fri, 30 Dec 2011 10:19:11 +0000 (UTC) (envelope-from mmakonnen@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 1CCBB8FC17; Fri, 30 Dec 2011 10:19:10 +0000 (UTC) Received: by yhfq46 with SMTP id q46so9835432yhf.13 for ; Fri, 30 Dec 2011 02:19:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=c40+07zuq7KRWgRun6mT3AF8m+k7DDSxUk6BuVw85ek=; b=R8y+oMCd3DS/2GwqwN2hN7I5ULPfVYWA6krOwZqQjhkZAO4U7I6RVN4xGYwtdor6ED o7jF84ANiFbWOK5lZyzjd64qdXNZAu9BU6DqkYv3FBV9c6SShXs53dam3B06TQiTNC5L nykqaQdi7Gg7jIPw5GsNZzYNOrDQPeFqFYcN4= MIME-Version: 1.0 Received: by 10.236.195.71 with SMTP id o47mr879987yhn.56.1325238558410; Fri, 30 Dec 2011 01:49:18 -0800 (PST) Sender: mmakonnen@gmail.com Received: by 10.146.232.4 with HTTP; Fri, 30 Dec 2011 01:49:18 -0800 (PST) In-Reply-To: References: Date: Fri, 30 Dec 2011 12:49:18 +0300 X-Google-Sender-Auth: MGyulz1Duiw4n8VRIFO-oZErffE Message-ID: From: Mike Telahun Makonnen To: Eygene Ryabinkin Content-Type: text/plain; charset=ISO-8859-1 Cc: gordon@freebsd.org, freebsd-rc@freebsd.org Subject: Re: Usage of the err() inside rc.d scripts 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, 30 Dec 2011 10:19:11 -0000 > > So, the question is: what is it good for and how people use it? > IIRC it's used in NetBSD as a fallback for very slow machines, on which forking a large number of processes, would delay start up too long. It exists in FreeBSD because at the time rc.d was introduced into FreeBSD we tried not to diverge from NetBSD too much. The idea was that a script from a NetBSD machine should be able to run on a FreeBSD machine and vice versa. However, that has been (mostly) abandoned now and over the past few years most of the NetBSD compatibility shims have been removed. I don't know if anyone uses this feature on FreeBSD (embedded systems maybe?). Cheers, Mike. From owner-freebsd-rc@FreeBSD.ORG Sat Dec 31 06:55:15 2011 Return-Path: Delivered-To: freebsd-rc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 049AD1065675; Sat, 31 Dec 2011 06:55:14 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CA0DF8FC16; Sat, 31 Dec 2011 06:55:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pBV6tExv095562; Sat, 31 Dec 2011 06:55:14 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pBV6tEcl095544; Sat, 31 Dec 2011 06:55:14 GMT (envelope-from linimon) Date: Sat, 31 Dec 2011 06:55:14 GMT Message-Id: <201112310655.pBV6tEcl095544@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-rc@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: conf/163727: [rc.d] [patch] The mountlate RCNG boot script cannot be disabled 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, 31 Dec 2011 06:55:15 -0000 Old Synopsis: The mountlate RCNG boot script cannot be disabled New Synopsis: [rc.d] [patch] The mountlate RCNG boot script cannot be disabled Responsible-Changed-From-To: freebsd-bugs->freebsd-rc Responsible-Changed-By: linimon Responsible-Changed-When: Sat Dec 31 06:54:51 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=163727 From owner-freebsd-rc@FreeBSD.ORG Sat Dec 31 07:58:40 2011 Return-Path: Delivered-To: freebsd-rc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D440106566C; Sat, 31 Dec 2011 07:58:40 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6D0E68FC0C; Sat, 31 Dec 2011 07:58:40 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pBV7weED074394; Sat, 31 Dec 2011 07:58:40 GMT (envelope-from dougb@freefall.freebsd.org) Received: (from dougb@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pBV7webJ074390; Sat, 31 Dec 2011 07:58:40 GMT (envelope-from dougb) Date: Sat, 31 Dec 2011 07:58:40 GMT Message-Id: <201112310758.pBV7webJ074390@freefall.freebsd.org> To: dteske@vicor.com, dougb@FreeBSD.org, freebsd-rc@FreeBSD.org, dougb@FreeBSD.org From: dougb@FreeBSD.org Cc: Subject: Re: conf/163727: [rc.d] [patch] The mountlate rc.d boot script cannot be disabled 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, 31 Dec 2011 07:58:40 -0000 Old Synopsis: [rc.d] [patch] The mountlate RCNG boot script cannot be disabled New Synopsis: [rc.d] [patch] The mountlate rc.d boot script cannot be disabled State-Changed-From-To: open->closed State-Changed-By: dougb State-Changed-When: Sat Dec 31 07:54:00 UTC 2011 State-Changed-Why: 1. What you're talking about is an extreme edge case. If you can't figure out how to properly configure these systems, then simply removing the script from /etc/rc.d is enough. 2. Don't attempt to mount critical remote file systems using DNS names. This has been true for as long as I can remember. 3. If you have critical remote systems that you can't afford to have hang in single user mode, put a serial console on them. Meta-notes: 1. I obeyed your disclaimer text and removed the second patch that you sent. 2. It hasn't been "rcng" for a long time now. The preferred term is rc.d. Responsible-Changed-From-To: freebsd-rc->dougb Responsible-Changed-By: dougb Responsible-Changed-When: Sat Dec 31 07:54:00 UTC 2011 Responsible-Changed-Why: I'm closing this. http://www.freebsd.org/cgi/query-pr.cgi?pr=163727 From owner-freebsd-rc@FreeBSD.ORG Sat Dec 31 16:08: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 36F83106566B; Sat, 31 Dec 2011 16:08:07 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id EE3A98FC08; Sat, 31 Dec 2011 16:08:06 +0000 (UTC) Received: from pps.filterd (ltcfislmsgpa02 [127.0.0.1]) by ltcfislmsgpa02.fnfis.com (8.14.4/8.14.4) with SMTP id pBVFdt4q002611; Sat, 31 Dec 2011 10:08:06 -0600 Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa02.fnfis.com with ESMTP id 1224vd05x8-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 31 Dec 2011 10:08:05 -0600 Received: from [10.0.0.103] (10.14.152.30) by smtp.fisglobal.com (10.132.206.17) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 31 Dec 2011 10:08:04 -0600 MIME-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset="us-ascii" From: Devin Teske In-Reply-To: <201112310758.pBV7webJ074390@freefall.freebsd.org> Date: Sat, 31 Dec 2011 08:08:03 -0800 Content-Transfer-Encoding: quoted-printable Message-ID: <8F16E728-1A94-4ECD-9D83-4A854AD7A702@fisglobal.com> References: <201112310758.pBV7webJ074390@freefall.freebsd.org> To: X-Mailer: Apple Mail (2.1084) X-Originating-IP: [10.14.152.30] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110, 1.0.211, 0.0.0000 definitions=2011-12-31_04:2011-12-30, 2011-12-31, 1970-01-01 signatures=0 Cc: freebsd-rc@FreeBSD.org Subject: Re: conf/163727: [rc.d] [patch] The mountlate rc.d boot script cannot be disabled 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, 31 Dec 2011 16:08:07 -0000 On Dec 30, 2011, at 11:58 PM, wrote: > Old Synopsis: [rc.d] [patch] The mountlate RCNG boot script cannot be dis= abled > New Synopsis: [rc.d] [patch] The mountlate rc.d boot script cannot be dis= abled >=20 > State-Changed-From-To: open->closed Should I take this one to the forums to get a wider consensus? Because everybody in the community I talk to agrees with me -- in the sense= that mountlate should be abled to be disabled for those that desire-to. > State-Changed-By: dougb > State-Changed-When: Sat Dec 31 07:54:00 UTC 2011 > State-Changed-Why:=20 >=20 > 1. What you're talking about is an extreme edge case. I completely disagree. About 10 years ago, our company paid into the FreeBSD community tens-of-tho= usands of dollars to make certain that NFS was both rock-stable and could b= e used as a production platform. Now, we're seeing that NFS is a second-class citizen (only that it is curre= ntly _impossible_ without modification of the FreeBSD system to have even o= ne single NFS mount in your fstab(5) without risking certain eventual death= for, being dropped into single-user mode). The fact of the matter is that we use NFS to "band" our BSD systems togethe= r and without any modification to the FreeBSD system, we've identified no l= ess than a half-dozen cases (that are _not_ extreme in any way) where the s= ystem boots into single-user mode. But then again, I'm sure that you'll tell me that a simple power-outage is = "extreme" -- in which case, even a power-outage can cause several hundreds = of machines to boot into single-user mode simply because there was a race-c= ondition between which machines would have DNS, which machines would have t= heir "companion PC's" boot just a smidge slower than the machines that moun= t-them. > If you can't figure > out how to properly configure these systems, We're resorting to insults now? Gee, thanks! > then simply removing the script > from /etc/rc.d is enough. You reject my patch and tell me to "simply remov[e] the script". This confu= ses me. I would have in all earnest thought this was not a possible outcome= . But hey... I guess that (removing the script) works too, just hadn't thou= ght of it. I'd still rather see the community embrace this simple patch. After-all, wh= at's the harm if some administrator wants to disable this script? Like you = say... deleting the script works too. But,... after deletion one cannot jus= t "simply change his mind" ... as he now has to scp the script out from ano= ther box (which hopefully there's a copy lying around somewhere). I think making the script toggle-able is better than just killing it (which= is dirty as it leavers no easy way to turn it back on; in a general sense). >=20 > 2. Don't attempt to mount critical remote file systems using DNS names. It doesn't matter if you use DNS names or not. If you don't use DNS names, = then the box can still drop to single-user mode if the destination is not m= ountable. This can occur for example in a power-outage and the machines are= not brought up in the right order or there is a momentary lapse caused by = different boot-speeds of different hardware. Trust me doug, we've been battling these cases for months. The tiny two-line patch that is required to make mountlate toggle-able seem= s to be the "least evil" -- that is, including comparison to "simply removi= ng the script" which in itself seems evil. > This > has been true for as long as I can remember.=20 That may be so, but we at VICOR have the distinct impression that somewhere= along the line between FreeBSD-4 (where we were extremely active -- hostin= g FreeBSD release parties at our office, contributing daily both monetarily= and code-wise back when 3 committers were actively employed here) and -CUR= RENT, that NFS was made a "second-class citizen". Back in the FreeBSD-4 days, we would have never imagined EVER making NFS cr= itical to boot into single-user mode, because we know that NFS fails all th= e time and furthermore, we expect to SSH in and execute "mount -a" to fix t= he problem. Mind you, I do see that there are a LOT of mechanisms for indicating via co= nfiguration that some network filesystem ought not to be critical to bootin= g into multi-user mode, but in practice, not a damned one of them works. I'= ve raised patches to fix "bg", I've raised patches to fix "late", and I've = even suggested now that the "mountlate" mechanism be able to be disabled if= -so-desired. The net-effect to all of this, is that we feel that the community is active= ly trying to prevent progress-forward in finding a way to prevent a network= filesystem from hanging the boot process, and we can't figure out WHY!!?? It's feeling like it's time to take this one to the forums. >=20 > 3. If you have critical remote systems that you can't afford to have hang > in single user mode, put a serial console on them. That's tantamount to a mandate to force our customers to build-out infrastr= ucture that they currently (a) do not have and (b) do not desire. Furthermore, we can't force our customers to do anything. If they say "no" = to serial consoles, we can't force them. That puts us in the unfortunate circumstance where we employ a field engine= er that could gladly fix the problem remotely at 2AM via logging into sshd = running in multi-user mode but alas... the system is stuck in single-user m= ode so the field engineer has to be dispatched at 2AM to go type a couple c= ommands (which seems ridiculous). >=20 > Meta-notes: >=20 > 1. I obeyed your disclaimer text I can't send e-mail without that being appended. I suggest you simply ignor= e it (the e-mail was directly addressed to the Gnats system and therefore t= he contents were _meant_ to be digested). > and removed the second patch that you sent. >=20 > 2. It hasn't been "rcng" for a long time now. The preferred term is rc.d. Thanks. >=20 >=20 > Responsible-Changed-From-To: freebsd-rc->dougb > Responsible-Changed-By: dougb > Responsible-Changed-When: Sat Dec 31 07:54:00 UTC 2011 > Responsible-Changed-Why:=20 >=20 > I'm closing this. Don't be surprised if it gets re-submitted. >=20 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D163727 --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-rc@FreeBSD.ORG Sat Dec 31 16:34:58 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 256A9106566B; Sat, 31 Dec 2011 16:34:58 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id D12DC8FC08; Sat, 31 Dec 2011 16:34:57 +0000 (UTC) Received: by iadj38 with SMTP id j38so34151776iad.13 for ; Sat, 31 Dec 2011 08:34:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=WvtR9qH4HLcA+n3EvhP9AIFwLZFUJEmMSfzXJU+fu+s=; b=hOBw5koEzOAbaHXInUfXBGAhze32hDdv/mRtZAh5PIJz/OjFG4XoHnLTHBrd5P9Y8Y 25TplsFI3oxLihCiZ9CEMdnIgLhjl/JtzxqwKVMECqZQ4Y9WmoDPK19iiX2Ao9I+cu7w 7U3zFGG5IbXno1KueP1YdRYHu2jmgoqDt1IpE= Received: by 10.43.51.69 with SMTP id vh5mr51312349icb.32.1325349297259; Sat, 31 Dec 2011 08:34:57 -0800 (PST) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.231.207.7 with HTTP; Sat, 31 Dec 2011 08:34:26 -0800 (PST) In-Reply-To: <8F16E728-1A94-4ECD-9D83-4A854AD7A702@fisglobal.com> References: <201112310758.pBV7webJ074390@freefall.freebsd.org> <8F16E728-1A94-4ECD-9D83-4A854AD7A702@fisglobal.com> From: Chris Rees Date: Sat, 31 Dec 2011 16:34:26 +0000 X-Google-Sender-Auth: a7UX_jZRpIiBILCuEtQo2YTSsiw Message-ID: To: Devin Teske Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dougb@freebsd.org, freebsd-rc@freebsd.org Subject: Re: conf/163727: [rc.d] [patch] The mountlate rc.d boot script cannot be disabled 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, 31 Dec 2011 16:34:58 -0000 On 31 December 2011 16:08, Devin Teske wrote: > > On Dec 30, 2011, at 11:58 PM, wrote: > >> Old Synopsis: [rc.d] [patch] The mountlate RCNG boot script cannot be di= sabled >> New Synopsis: [rc.d] [patch] The mountlate rc.d boot script cannot be di= sabled >> >> State-Changed-From-To: open->closed > > Should I take this one to the forums to get a wider consensus? > > Because everybody in the community I talk to agrees with me -- in the sen= se that mountlate should be abled to be disabled for those that desire-to. > > >> State-Changed-By: dougb >> State-Changed-When: Sat Dec 31 07:54:00 UTC 2011 >> State-Changed-Why: >> >> 1. What you're talking about is an extreme edge case. > > I completely disagree. > > About 10 years ago, our company paid into the FreeBSD community tens-of-t= housands of dollars to make certain that NFS was both rock-stable and could= be used as a production platform. > > Now, we're seeing that NFS is a second-class citizen (only that it is cur= rently _impossible_ without modification of the FreeBSD system to have even= one single NFS mount in your fstab(5) without risking certain eventual dea= th for, being dropped into single-user mode). > > The fact of the matter is that we use NFS to "band" our BSD systems toget= her and without any modification to the FreeBSD system, we've identified no= less than a half-dozen cases (that are _not_ extreme in any way) where the= system boots into single-user mode. > > But then again, I'm sure that you'll tell me that a simple power-outage i= s "extreme" -- in which case, even a power-outage can cause several hundred= s of machines to boot into single-user mode simply because there was a race= -condition between which machines would have DNS, which machines would have= their "companion PC's" boot just a smidge slower than the machines that mo= unt-them. > > > >> If you can't figure >> out how to properly configure these systems, > > We're resorting to insults now? Gee, thanks! > > > >> then simply removing the script >> from /etc/rc.d is enough. > > You reject my patch and tell me to "simply remov[e] the script". This con= fuses me. I would have in all earnest thought this was not a possible outco= me. But hey... I guess that (removing the script) works too, just hadn't th= ought of it. > > I'd still rather see the community embrace this simple patch. After-all, = what's the harm if some administrator wants to disable this script? Like yo= u say... deleting the script works too. But,... after deletion one cannot j= ust "simply change his mind" ... as he now has to scp the script out from a= nother box (which hopefully there's a copy lying around somewhere). > > I think making the script toggle-able is better than just killing it (whi= ch is dirty as it leavers no easy way to turn it back on; in a general sens= e). > > > >> >> 2. Don't attempt to mount critical remote file systems using DNS names. > > It doesn't matter if you use DNS names or not. If you don't use DNS names= , then the box can still drop to single-user mode if the destination is not= mountable. This can occur for example in a power-outage and the machines a= re not brought up in the right order or there is a momentary lapse caused b= y different boot-speeds of different hardware. > > Trust me doug, we've been battling these cases for months. > > The tiny two-line patch that is required to make mountlate toggle-able se= ems to be the "least evil" -- that is, including comparison to "simply remo= ving the script" which in itself seems evil. > > > >> This >> has been true for as long as I can remember. > > That may be so, but we at VICOR have the distinct impression that somewhe= re along the line between FreeBSD-4 (where we were extremely active -- host= ing FreeBSD release parties at our office, contributing daily both monetari= ly and code-wise back when 3 committers were actively employed here) and -C= URRENT, that NFS was made a "second-class citizen". > > Back in the FreeBSD-4 days, we would have never imagined EVER making NFS = critical to boot into single-user mode, because we know that NFS fails all = the time and furthermore, we expect to SSH in and execute "mount -a" to fix= the problem. > > Mind you, I do see that there are a LOT of mechanisms for indicating via = configuration that some network filesystem ought not to be critical to boot= ing into multi-user mode, but in practice, not a damned one of them works. = I've raised patches to fix "bg", I've raised patches to fix "late", and I'v= e even suggested now that the "mountlate" mechanism be able to be disabled = if-so-desired. > > The net-effect to all of this, is that we feel that the community is acti= vely trying to prevent progress-forward in finding a way to prevent a netwo= rk filesystem from hanging the boot process, and we can't figure out WHY!!?= ? > > It's feeling like it's time to take this one to the forums. > > > >> >> 3. If you have critical remote systems that you can't afford to have han= g >> in single user mode, put a serial console on them. > > That's tantamount to a mandate to force our customers to build-out infras= tructure that they currently (a) do not have and (b) do not desire. > > Furthermore, we can't force our customers to do anything. If they say "no= " to serial consoles, we can't force them. > > That puts us in the unfortunate circumstance where we employ a field engi= neer that could gladly fix the problem remotely at 2AM via logging into ssh= d running in multi-user mode but alas... the system is stuck in single-user= mode so the field engineer has to be dispatched at 2AM to go type a couple= commands (which seems ridiculous). > > > >> >> Meta-notes: >> >> 1. I obeyed your disclaimer text > > I can't send e-mail without that being appended. I suggest you simply ign= ore it (the e-mail was directly addressed to the Gnats system and therefore= the contents were _meant_ to be digested). > > > >> and removed the second patch that you sent. >> >> 2. It hasn't been "rcng" for a long time now. The preferred term is rc.d= . > > Thanks. > > >> >> >> Responsible-Changed-From-To: freebsd-rc->dougb >> Responsible-Changed-By: dougb >> Responsible-Changed-When: Sat Dec 31 07:54:00 UTC 2011 >> Responsible-Changed-Why: >> >> I'm closing this. > > Don't be surprised if it gets re-submitted. > Re-submitting won't help your cause. However... I do think you have a slight bit of a point-- Doug, is there a reason that the patch is harmful? Chris From owner-freebsd-rc@FreeBSD.ORG Sat Dec 31 23:22:37 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 ED3381065678; Sat, 31 Dec 2011 23:22:37 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 1381F202701; Sat, 31 Dec 2011 23:21:53 +0000 (UTC) Message-ID: <4EFF9911.5020603@FreeBSD.org> Date: Sat, 31 Dec 2011 15:21:53 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Chris Rees References: <201112310758.pBV7webJ074390@freefall.freebsd.org> <8F16E728-1A94-4ECD-9D83-4A854AD7A702@fisglobal.com> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-rc@freebsd.org Subject: Re: The mountlate rc.d boot script cannot be disabled 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, 31 Dec 2011 23:22:38 -0000 On 12/31/2011 8:34 AM, Chris Rees wrote: > Doug, is there a reason that the patch is harmful? 1. An unlimited number of knobs is not a virtue, it just leads to more user confusion. 2. The harm caused by a user accidentally flipping this is much greater than any possible benefit that it could provide. I think Jilles had a good point, it's likely that the best actual change to be made here is better documentation of the failok knob for fstab. In response to Devin, no matter what you do at this point you're already making some kind of change to the system to get the behavior you want (applying a patch, flipping a knob, whatever). Therefore it's just as easy for you to handle this problem by removing the script from /etc/rc.d, which is just a different kind of change, and will 100% solve your problem (albeit with a fairly big hammer). Also, having a serial console on critical remote systems is sysadmin 101. If your customers don't understand that it's up to you(pl.) to gently educate them about it. Even if we were able to find a 100% successful solution to all of your NFS problems that doesn't mean that tomorrow a system won't fail to boot for some other reason. hth, Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/