Thu, Jan 12, 2012 at 02:38:16PM -0500, John Baldwin wrote: > On Thursday, January 12, 2012 9:35:05 am Eygene Ryabinkin wrote: > > True, and it was suggested by Doug Barton. But why bother when > > the 'quiet' keyword is reserved for such cases? > > Hmm, that's not quite how I see this. Either /etc/rc.d/dhclient > should silently exit if dhcpif is not true for the given interface, > or it should always whine IMO.
It should tell one why it won't start DHCP on the interface, so it
should whine at least for the ordinary usage (service dhclient start
<if>), otherwise it will be hard to understand what's going on.
> Given that everywhere else uses dhcpif to decide if dhclient should
> be run, it seems that an explicit test of that should be used here
> as well, even if it means an extra script. In short, this approach
> is not consisent with all other users of the dhclient script,
As I see, the only other conditional consumer of the dhclient script
is /etc/network.subr, procedure ifconfig_up. And it has the other
reason to invoke dhcpif: it determines if dhclient should be run
synchronously and invokes it explicitely only in this case; for the
asynchronous dhclient it relies on the devd to do the work once the
interface will come up.
> and this seems a hackish approach whose primary goal is to avoid
> having devd use a wrapper script. Perhaps that goal is worth the
> tradeoff, but it's not really clean.
Well, partly my reasoning for suppressing the error message was the
following one: 'quiet' will silence the messages about non-enabled
service (via <foo>_enabled) that is set via rc.conf and in DHCP case
we also have rc.conf knob (per-interface 'dhcp' keyword), so that's
not a different case.
But seems like the whole problem is that I used the err() function
instead of doing 'echo $errmsg; exit 1'. Such code shouldn't be
conditionalized for the devd, since it is only syslog message that
worried people; devd doesn't care what is written to the standard
output or the standard error by the scripts it invokes once it become
the daemon, since everything goes to /dev/null after calling
daemon(3).
So, seems like that the following dhclient_pre_check() will make
everyone happy:
{{{
dhclient_pre_check()
{
if [ -z "${rc_force}" ] && ! dhcpif $ifn; then
echo "'$ifn' is not a DHCP-enabled interface"
exit 1
fi
}
}}}
Hadn't tested it yet, but will do it today.
> By your argument, btw since we use quietstart during boot, ifn_start
> shouldn't even check dhcpif at all now, but just always run the
> dhclient script (and if you did make that change, I would protest that
> it was very wrong).
Well, ifn_start (ifconfig_up to be precise) calls 'dhclient start'
and not the 'quietstart'. Moreover, as I had explained, there is
other dance with syncdhcpif there, so it can't just invoke dhclient
unconditionally.
The related topic: in the process of grepping for dhclient within
/etc, I had found that /etc/netstart still wants to invoke it. But it
will do a lone '/etc/rc.d/dhclient quietstart' and this will never
be useful in the current state of dhclient: it will refuse to process
any commands without the interface being specified. And since we
have the invocation of /etc/rc.d/netif just two lines above, I think
that it will be good to remove call to dhclient from /etc/netstart.
At the time of the original addition of call to dhclient to /etc/netstart
(r114213), dhclient script had another form,
http://svnweb.freebsd.org/base/head/etc/rc.d/dhclient?revision=113759&view=markup&pathrev=114213
and it was really a normal rc.d script that requires only one argument.
Now it is more of a helper-type script.
.
Am I missing something important here or the removal can really be
done?
Thanks.
--
Eygene Ryabinkin ,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
pgpZmlj0ZCr1e.pgp
Description: PGP signature
