I used dhcpcd_flags="-w" -- it looks like both problems want away.
But will I have this prob again, when spring time is set-forward by 1h ?? On Sat, Nov 23, 2024 at 1:01 PM Greg Troxel <g...@lexort.com> wrote: > > Benny Siegert <bsieg...@gmail.com> writes: > > > Am 23.11.24 um 02:38 schrieb Steve Rikli: > >> Your rc.conf settings look OK; this error from 'ntpdate': > >> > Exiting, name server cannot be used: Temporary failure in name > >> > resolution (2)/etc/rc.d/ntpdate exited with code 1 > >> is most likely telling you that "2.netbsd.pool.ntp.org" is unable to > >> be > >> resolved. Often this is a DNS config issue, sometimes a problem with > >> your system's network config, or possibly the local network itself (e.g. > >> if your gateway is off-the-air or something similar). > > > > I was seeing the same on a Raspberry Pi with NetBSD recently. This > > happens because dhcpcd goes into the background while waiting for an > > IP address, so booting can continue. If the DHCP process is not done > > by the time ntpdate or ntpd start running, you will get this message. > > > > I solved it, by adding this line to rc.conf: > > > > dhcpcd_flags="-w" > > > > This will make dhcpcd block until it has an IP address assigned. Note > > that this means the boot will take a long time when there is no > > network for whatever reason. > > I have also been seeing "daemons starting before IP address don't end up > in a happy state". Arguably, they are buggy, but fixing is easier said > thana done. > > The -w is appealing, but I also don't want it to block forever. For > example, a home router/everything box, where one interface is getting an > address from the ISP. If the ISP or the connection is broken, I still > want the machine to boot. Even if some daemon is not happy. But most > importantly I want to be able to ssh in locally. > > So I would like something that says "wait, but only up to 60s, and after > that background while still trying". But, reading the man page, it > looks like: > > there is already a wait of 30s, probably > > if the interface has carrier, then there is a lease attempt before > backgrounding. > > > so it seems that you shouldn't need to do what you did.
