Circular dependency between local_unbound and ntpd?

Charles Sprickman spork at bway.net
Tue Jul 14 18:31:56 UTC 2015


On Jul 14, 2015, at 10:47 AM, Paul Mather <paul at gromit.dlib.vt.edu> wrote:

> On Jul 14, 2015, at 10:33 AM, krad <kraduk at gmail.com> wrote:
>> 
>> As
>> 
>> $ grep REQUIRE /etc/rc.d/ntpd
>> # REQUIRE: DAEMON ntpdate FILESYSTEMS devfs
>> 
>> 
>> You could set something similar to the following in the rc.conf
>> 
>> ntpdate_hosts="a.b.c.d w.x.y.z"
>> ntpdate_enable=yes
> 
> Thanks for that suggestion.  I assume the "a.b.c.d w.x.y.z" are IP addresses, not hostnames, otherwise we'd have the same problem.
> 
> The /etc/rc.d/ntpdate startup script has a "REQUIRE: NETWORKING ..." and /etc/rc.d/local_unbound has a "BEFORE: NETWORKING" in it, meaning it will be running before ntpdate runs.  That means DNS resolution will require an accurate clock and, I assume, mean that ntpdate will require IP addresses, too?
> 
> So, it still comes down to this: do I need to know the IP address of an NTP server to be able to use local_unbound safely with NTP?

Hopefully not.  I have a client with a number of Mikrotik routers sprinkled around upstate.  They did not have an NTP server to point to, so I used a pool server.  Mikrotik will take a hostname, but it saves an IP.  A year later I see a few not reestablish OpenVPN connections after power failures, spend an hour troubleshooting, turns out that those IPs were no longer NTP servers, the box thought it was 1970, and that causes the VPN to fail.

TL;DR, don’t save NTP servers by IP in config files.

Charles

> 
> Cheers,
> 
> Paul.
> 
> 
>> 
>> 
>> 
>> 
>> On 14 July 2015 at 14:43, Paul Mather <paul at gromit.dlib.vt.edu <mailto:paul at gromit.dlib.vt.edu>> wrote:
>> I believe I ran afoul of a circular dependency between local_unbound and ntpd on my 10.2-PRERELEASE system.  I use a stock /etc/ntp.conf and use ntpd_sync_on_start="YES".
>> 
>> Last night, a BIOS settings reset cause my CMOS clock to go WAY out of synch for the first time.  No problem, I thought: NTP will correct it at boot.
>> 
>> Wrong!
>> 
>> When my system booted, the time was not corrected.  Also, DNS resolution was not working.  I figured out it was because local_unbound relies on an accurately set clock, but the clock could not be set accurately because my stock ntp.conf requires working DNS resolution to reach the NTP servers.
>> 
>> That sounds like a potential circular dependency to me.
>> 
>> My workaround at the time was to look up 0.freebsd.pool.ntp.org <http://0.freebsd.pool.ntp.org/> on another system; stop ntpd; then do a ntpdate using the IP addresses to set the clock. Once the clock was set accurately, things were all hunky dory.
>> 
>> Does anyone have any suggestion for an automatic way around this?  I guess one way would be to put the IP address of an NTP server into my ntp.conf file, so at least one would be reachable without needing a working DNS?
>> 
>> My main concern is for those systems like my Raspberry Pi and Beaglebone Black that don't have a battery-backed clock.  I currently don't use local_unbound on those, but it seems like I'd encounter this problem routinely if I did.
>> 
>> Cheers,
>> 
>> Paul.
>> _______________________________________________
>> freebsd-stable at freebsd.org <mailto:freebsd-stable at freebsd.org> mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>
>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org <mailto:freebsd-stable-unsubscribe at freebsd.org>"
>> 
> 
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"



More information about the freebsd-stable mailing list