On 3/10/19 4:11 AM, Rick Thomas wrote: > If ntpsec implemented the "preempt" option on "peer" directives, the > first "peer" would be revisited after a few minutes and all would be > well. But it doesn't. So the first "peer" is as if it never existed.
What leads you to this conclusion, specifically about preempt? The way pool directives work is that they are re-evaluated until it reaches maxclock: https://docs.ntpsec.org/latest/discover.html I'm not 100% sure how multiple independent pools (like you have here) will intersect. It's possible that ntpd is spinning up all the associations from the public pool. If only for testing, what happens if you comment out the public pool? Does it behave correctly then? On 3/11/19 2:46 AM, Rick Thomas wrote: > Edited /lib/systemd/system/ntpsec-systemd-netif.path As you figured out, this is the wrong place. You want ntpsec.service. >> Mar 11 00:23:51 cube ntpd[354]: DNS: dns_probe: us.pool.ntp.org, >> cast_flags:8, flags:101 >> Mar 11 00:23:51 cube ntpd[354]: DNS: dns_check: processing us.pool.ntp.org, >> 8, 101 >> Mar 11 00:23:51 cube ntpd[354]: DNS: dns_check: DNS error: -3, Temporary >> failure in name resolution >> Mar 11 00:23:51 cube ntpd[354]: DNS: dns_take_status: us.pool.ntp.org=>temp, >> 9 >> Mar 11 00:23:52 cube ntpd[354]: DNS: dns_probe: pool.rcthomas.org, >> cast_flags:8, flags:121 >> Mar 11 00:23:52 cube ntpd[354]: DNS: dns_check: processing >> pool.rcthomas.org, 8, 121 >> Mar 11 00:23:52 cube ntpd[354]: DNS: dns_check: DNS error: -3, Temporary >> failure in name resolution >> Mar 11 00:23:52 cube ntpd[354]: DNS: dns_take_status: >> pool.rcthomas.org=>temp, 9 I agree with your conclusion that DNS is not ready when ntpd started. >> Mar 11 00:23:56 cube ntpd[354]: IO: Listen normally on 4 eth0 >> 192.168.3.129:123 >> Mar 11 00:23:56 cube ntpd[354]: IO: Listen normally on 5 eth0 >> [fe80::d263:b4ff:fe00:912f%2]:123 >> Mar 11 00:23:56 cube ntpd[354]: DNS: dns_probe: pool.rcthomas.org, >> cast_flags:8, flags:121 >> Mar 11 00:23:56 cube ntpd[354]: DNS: dns_check: processing >> pool.rcthomas.org, 8, 121 >> Mar 11 00:23:56 cube ntpd[354]: DNS: Pool taking: 192.168.3.207 >> Mar 11 00:23:56 cube ntpd[354]: DNS: Pool taking: 192.168.3.111 >> Mar 11 00:23:56 cube ntpd[354]: DNS: Pool taking: 192.168.3.4 >> Mar 11 00:23:56 cube ntpd[354]: DNS: Pool taking: 192.168.1.14 What about this, though? Those are private IP addresses, so I assume those are coming from pool.rcthomas.org. >> Mar 11 00:23:56 cube ntpd[354]: DNS: dns_take_status: >> pool.rcthomas.org=>good, 8 This sure looks like it resolved correctly. What is the output from: ntpq -p Also note that the definition of network-online.target can vary and may or may not represent what you actually want. https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ If there's a bug here, I'd like to get it reported upstream so it can be fixed. However, I am very skeptical of the idea that ntpd should, by default, wait until the network is online before starting. That prevents useful configurations like local refclocks, with no advantage if ntpd simply retries the network connections periodically, which I believe it is supposed to do. -- Richard
