Hi Richard, My observations follow your quote…
> On Mar 11, 2019, at 12:30 PM, Richard Laager <rlaa...@wiktel.com> wrote: > > 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 You are correct that the private IP addresses are coming from “pool.rcthomas.org” and the public addresses are from “us.pool.ntp.org”. It may be worth noting that each of the two pools resolves (at any given time) to just four IP addresses, and the conf file specifies minsane 5 (so as to always have at least one sane server from each of the pools) and minclock 7 (to allow two spares if one or more of the servers goes insane). If that’s not a good idea, please correct me. I’ve tried various combinations and orders of the “pool” statements. What always happens is that they both are initially rejected; then the last one (and only the last one — whether it’s the private one or the public one) resolves OK on the next attempt and ntpsec connects to those servers — It almost looks as if (for some reason) the first one, having been rejected, is forgotten about but (again, for some reason) the last one is remembered and retried. The first pool statement is eventually retried, but not for a period of several minutes (5 or 10?) Something (I don’t know what) causes it to be re-considered, and this time (of course) it resolves. I just last night discovered the re-consideration after a long delay thing. Previously I would always loose patience and restart ntpsec before that timeout — so I didn’t see it. I thought (though I may be wrong) that “preempt” was supposed to shorten that timeout to something more reasonable. Please enlighten me if I’m mistaken! In any case, the net result is that ntpsec does not synchronize the system clock for a period of up to 10 minutes after a reboot. Thanks! Rick
