Date: Sat, 24 Dec 2011 15:21:11 +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: <n2Hlz4MXZMNcNzN56fSf6/or7Ig@YnbH/K3/Y1Z96RV2jTofcGuSPJI> In-Reply-To: <4EF589DF.9060606@FreeBSD.org> <4EF4EF48.9010503@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--17pEHd4RhPHOinZp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Doug, *, good day.
Fri, Dec 23, 2011 at 01:14:48PM -0800, Doug Barton wrote:
> > Since the current rc.subr script has the following snippet,
> > {{{
> > if [ -n "${rcvar}" -a "$rc_arg" !=3D "rcvar" -a "$rc_ar=
g" !=3D "stop" ] ||
> > [ -n "${rcvar}" -a "$rc_arg" =3D "stop" -a -z "${rc=
_pid}" ]; then
> > if ! checkyesno ${rcvar}; then
> > if [ -n "${rc_quiet}" ]; then
> > return 0
> > fi
> > echo -n "Cannot '${rc_arg}' $name. Set =
${rcvar} to "
> > echo -n "YES in /etc/rc.conf or use 'on=
e${rc_arg}' "
> > echo "instead of '${rc_arg}'."
> > return 0
> > fi
> > fi
> > }}}
>=20
> You're misunderstanding the purpose of the above code. It's there so
> that you can do 'service foo stop' even if foo_enable is not set.
Huh? OK, let's translate this code snippet to the human language.
Here we go:
- if 'rcvar' is not empty and the command is not 'rcvar' (that just
shows the current and default status of the corresponding rc.conf
variable) and the command is not 'stop'
OR
- if 'rcvar' is not empty and the command is 'stop' and ("but" in the
human language) we have no PID for the daemon
then we will bail out silently if rc_quiet is set or will print an error
message and bail out.
Soo, yes -- it allows us to do the 'stop' even if the service is
disabled, but only if we really have the daemon running. But I am not
talking about the purpose of the condition, I am talking about the
semantics of the rc_quiet. And to talk about the semantics we should
invert you assertion (that more-or-less correctly states when the code
inside the outer 'if' clause is not executed and rc.d script will
continue its operations) and to count the cases when we will enter the
body of the outer 'if' statement. And it boils to every other case,
but the ones cited above. In most cases, rc_quiet in this snippet
will be consulted when the service won't be enabled in rc.conf; I think
you won't be telling that I am wrong here?
Moreover, as Mike (mtm@) explained, the "quiet" keyword was invented
precisely to keep devd stuff to be silent:
{{{
The rc_quiet knob was introduced to prevent devd spamming the console
when starting services that weren't enabled in rc.conf. It was also
overloaded to prevent unnecessary boot time clutter on the console.
}}}
> > I think that error message about non-DHCP-enabled interface falls
> > into the same category=20
>=20
> It does not.
Please, explain your point here. (*)
> >> It was not intended to mask "error" or "debug" messages.
> >=20
> > It is not my intention as well: I care about masking only certain class=
es
> > of error and informational messages with rc_quiet; my patch to rc.subr.8
> > documents all current cases where it is appropriate.
>=20
> Our opinions differ on this point.
I think that our opinions differ at the word "appropriate", but not on
the whole assertion of mine. Am I correct?
> > It is the internal problem of the devd that spams the first group
> > of people
>=20
> So adjust devd.conf.
Well, as the initial rationale of having the 'quiet' prefix was to
quieten the devd stuff (and it is really quiet -- if you will glance
over /etc/devd.conf, you will see that is just starts/stops the stuff
upon events and doesn't care if the corresponding service is enabled;
the dhclient culprit was just in additional rc.conf item -- "dhcp" in
the interface configuration, if we would talk only about
dhclient_enabled variable, there will be no current thread -- the case
when it is not enabled _already_ handled by the /etc/rc.subr.
So, in my view, you should either explain me the point where I have
the faulty logics (as I had asked in this email, 5 paragraphs above,
marked as '(*)') or the rc.subr snipped we're talking about should be
freed from the check of rc_quiet status and the error message must be
printed every time.
Please, note, I am using "should" not to oblige you to do what I am
saying, but just to express my thoughts about this semantical problem.
Sat, Dec 24, 2011 at 12:14:23AM -0800, Doug Barton wrote:
> On 12/24/2011 00:06, Gleb Smirnoff wrote:
> > Do you suggest to adjust devd.conf in svn, or do you think that
> > zillions of server FreeBSD installations should modify the default
> > devd.conf to get rid of this spamming?=20
>=20
> There are zillions of FreeBSD servers with wlan interfaces?
Excuse me, but you seem to hadn't glanced over the /etc/devd.conf.
Dhclient is called on all appropriate interface types, not only for
802.11 ones:
{{{
#
# Try to start dhclient on Ethernet-like interfaces when the link comes
# up. Only devices that are configured to support DHCP will actually
# run it. No link down rule exists because dhclient automatically exits
# when the link goes down.
#
notify 0 {
match "system" "IFNET";
match "type" "LINK_UP";
media-type "ethernet";
action "/etc/rc.d/dhclient quietstart $subsystem";
};
notify 0 {
match "system" "IFNET";
match "type" "LINK_UP";
media-type "802.11";
action "/etc/rc.d/dhclient quietstart $subsystem";
};
}}}
And, I bet, there are zillions of FreeBSD servers with Ethernet
interfaces for some sane definition of "zillion" as applied to the
FreeBSD community. In other words, the majority of FreeBSD servers
are running Ethernet interfaces and every 'ifup' event will result
in the spam from the devd(8).
--=20
Eygene Ryabinkin ,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
--17pEHd4RhPHOinZp
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
iF4EAREIAAYFAk71tacACgkQFq+eroFS7PuzGAD9GdYd3ZWMCu9u3Lx5jcyAhKBW
lA6cBIm402bs2CpmuFEBAJadWen9zD1lmkcha2CiBgS/3RzLiGr/cyk3oqXjWAje
=G/tC
-----END PGP SIGNATURE-----
--17pEHd4RhPHOinZp--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?n2Hlz4MXZMNcNzN56fSf6/or7Ig>