Date: Sat, 19 Nov 2011 09:29:54 +0400 From: Eygene Ryabinkin <rea@freebsd.org> To: Garrett Cooper <yanegomi@gmail.com>, d@delphij.net Cc: mtm@freebsd.org, Doug Barton <dougb@freebsd.org>, freebsd-rc@freebsd.org Subject: Re: Annoying ERROR: 'wlan0' is not a DHCP-enabled interface Message-ID: <3EG8fAEe6lZEtr/D6Pw60YTcoYU@YnbH/K3/Y1Z96RV2jTofcGuSPJI> In-Reply-To: <4EC6C9A4.3000006@delphij.net> <CAGH67wRBBtKm5K8iNPpB2_JGwFnxL4Gif1gMxR0sPe=bro4Jdw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--ylS2wUBXLOxYXZFQ Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Gentlemen, good morning. Fri, Nov 18, 2011 at 12:59:08PM -0800, Garrett Cooper wrote: > 2011/11/18 Eygene Ryabinkin <rea@freebsd.org>: > > Well, what about the silent output from 'cc -o test test.c' when > > you have no file test.c or the compiler is absent? =9AIt is the same > > thing (as I see it) and in this case will you expect that the binary > > 'test' will be compiled and ready for use or not? =9AI will, but this > > can be my personal delusion. >=20 > This is different because you personally are running cc to do a > particular task. This noise is emitted unnecessarily by automated > tasks which are in the default system, which is more annoying for > standard users, like me. Hmm, automated tasks (devd in our case) run 'quietstart', not bare 'start', so my latest patch that was announced for the testing yesterday just tries to cope with this situation: no noise will be produced for the 'quiest<op>', but bare '<op>' will spit a reason for skipping DHCP client run on non-DHCP interface. I believe that this fits to your expectations: intended invocation via 'start' will throw a verbose error, but automated one via 'quietstart' -- won't. So, we seem to be closer to some consensus, aren't we? Fri, Nov 18, 2011 at 01:09:56PM -0800, Xin LI wrote: > On 11/18/11 12:45, Eygene Ryabinkin wrote: > > Well, when I invoke 'service dhclient start em0' and em0 isn't=20 > > DHCP-enabled, I want to see some diagnostics on why I was not able > > to get DHCP on that interface. Return code isn't that visible (I > > can, of course, always run it as 'service dhclient start em0 || > > echo failed'), but I am not up to typing more than needed and I > > should see the real reason for absence of DHCP-assigned address in > > that case, be it the non-DHCP-enabled interface or some other > > problem. >=20 > Thinking again I believe that your approach is more sensible. > Thanks! Thank you! So, seems like the only known caveat (raised by Doug) is the semantics of the 'quiet' prefix. Looking at the NetBSD CVS, http://cvsweb.netbsd.org/bsdweb.cgi/src/etc/rc.subr?annotate=3D1.88&only_= with_tag=3DMAIN I see that they have no 'quiet' operations, so this is FreeBSD addition made by mtm@, http://svnweb.freebsd.org/base?view=3Drevision&revision=3D175676 Judging by that change and the fact that rc_quiet is mostly used internally to the rc.subr and currently its only use is to skip some diagnostics in the following snippet, {{{ if [ -n "${rcvar}" -a "$rc_arg" !=3D "rcvar" -a "$rc_arg" != =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 ${rc= var} to " echo -n "YES in /etc/rc.conf or use 'one${r= c_arg}' " echo "instead of '${rc_arg}'." return 0 fi fi }}} I would say that my (ab)use of it in the patch perfectly fits the cited usage. That's not an excuse if the semantics of rc_quiet will be different from its current usage, but since we have no well-documented semantics apart from "Don't output some diagnostics" inside /etc/rc.subr, may be we can just extend this explanation based on the current usage and the common sense, add that to the manual page of rc.subr and go on? Any thoughts on this? --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --ylS2wUBXLOxYXZFQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iF4EAREIAAYFAk7HPtIACgkQFq+eroFS7Pt+/AD/W4dj1FzUOLdCxi783id0APAV sIpJBZnnrG1SLSstomEA/jQFO0xDYOqjoIM+tIDJn1tfq73HGUZzPIai+oTHL+eB =e4RD -----END PGP SIGNATURE----- --ylS2wUBXLOxYXZFQ--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EG8fAEe6lZEtr/D6Pw60YTcoYU>