the main openntpd server on my network had accidentally been without a connection to the internet for several weeks and thus unable to connect to its configured remote clock sources. Oddly enough, "ntpctl -sa" would still output a status of "clock synced, stratum 2". Other machines on the network using this server as their clock source would report a stratum of 3.
I would have expected openntpd to consider its clock as out of sync after some timeout and notify downstream hosts accordingly. I'm not sure how this case is intended to be handled as per the NTP protocol. I have, however, seen the ntp.org ntpd report a stratum of 16 in this case so clients further downstream can detect that there is a problem.
I have since reconnected the affected machine and things are back to normal. Let me know if you'd like me to perform any additional tests. It appears that this can be easily replicated by disconnecting a single openntpd server and watching the output of "ntpctl -sa" on that machine.
Thank you, I can reproduce this. It's a generic problem with OpenNTPD and not specific to the FreeBSD port. I will raise the issue with upstream.
Is this PR still relevant?
(In reply to Mark Linimon from comment #3)
Well, the bug still exists. In fact, it still exists in the very latest ntpd on OpenBSD-current.
On the other hand, nobody else ever seems to have stumbled over this. I guess NTP servers just don't disappear in practice. I'll try to raise it with upstream again.
I'm fine with closing this bug or keeping it open indefinitely.
A commit references this bug:
Date: Sun Sep 13 14:14:27 UTC 2020
New revision: 548477
Merge back fixes from OpenBSD 6.8-beta:
If no replies are received for a while due to connectivity issues,
go into unsynced mode.
Reported by: Rene Wagner <firstname.lastname@example.org>
Obtained from: OpenBSD
This has finally been fixed upstream.