Re: Re: Annoyance with recent parallelism in rc.d

From: Alexey Shuvaev <shuvaev_at_physik.uni-wuerzburg.de>
Date: Mon, 16 Feb 2009 22:01:18 +0100
On Mon, Feb 16, 2009 at 06:32:23PM +0300, Mike Makonnen wrote:
> Alexey Shuvaev wrote:
>> I have ntpd failing to resolve dns names.
>> I have noticed this since appr. 1.350 of etc/defaults/rc.conf (12 days ago).
>> I was hoping this will go away...
>>
>> [snip]
>>
>> Since, rc.d/defaultroute has the ability to wait for a
>> default route to show up we can turn this knob back on
>> without screwing subsequent daemons that expect to be
>> able to talk to the outside world.
>>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> Seems it is not the case...
>> Interesting: setting background_dhclient="NO" does not
>> solve the issue. Maybe something else was changed?
>> My current 'workaroud' is synchronous_dhclient="YES"
>
> Please see my reply to the previous email in this thread. The problem  
> was not this commit, but the one before it.  Your setup used to work as  
> a side-effect of rc.d/defaultroute's previous behavior.
>
Rev. 1.4 of rc.d/defaultroute.
Ok, what should I do to have network daemons happy on startup?
I am on a LAN so always have plugged-in cable.
I do see on the console:
msk0: link state changed to DOWN
msk0: link state changed to UP
                   got link
msk0: link state changed to DOWN
Starting Network: lo0 msk0.
msk0: link state changed to UP
msk0: link state changed to DOWN

AFAIK some NIC (or PHY-s?) require some sort of reset to handle some
events.
Should I live with synchronous_dhclient="YES" or something else?

Thanks,
Alexey.
Received on Mon Feb 16 2009 - 20:01:22 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:42 UTC