Date: Sun, 25 Dec 2011 14:21:04 +0400 From: Eygene Ryabinkin <rea@freebsd.org> To: Doug Barton <dougb@FreeBSD.org> Cc: Pyun Yong-Hyeon <pyunyh@gmail.com>, freebsd-rc@freebsd.org, Garrett Cooper <yanegomi@gmail.com>, Gleb Smirnoff <glebius@FreeBSD.org>, d@delphij.net Subject: Re: Annoying ERROR: 'wlan0' is not a DHCP-enabled interface Message-ID: <s/Yu%2BoDFeN5aqq7gOss96iMJJKY@YnbH/K3/Y1Z96RV2jTofcGuSPJI> In-Reply-To: <4EF6401E.3080902@FreeBSD.org> References: <n2Hlz4MXZMNcNzN56fSf6/or7Ig@YnbH/K3/Y1Z96RV2jTofcGuSPJI> <4EF6401E.3080902@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?s/Yu%2BoDFeN5aqq7gOss96iMJJKY>