I've noticed that on any system I've configured with some of the various NTP pool servers that the daemon on my linux systems gets various and changing NTP servers from time to time. This causes the NTP Peer service to go into an unknown state since the previous servers have gone away replaced by other servers that are served out by the pool addresses.
Is there anyway to cleanly handle this? I find that occasionally I have to re-inventory those clients to get the new Peers set and while it's just an annoyance, if there's a clean way to deal with it I'd like to know what that is. I could just check on the NTP Time only and not inventory each Peer but I kind of like seeing the various peers and their stats. I've thought about just using specific individual servers but that seems to go against the purpose of the NTP pools that are available.
···
--
//- Fixer of that which is broke -//
//- Home = sberg@mississippi.com -//
//- Sinners can repent, but stupid is forever. -//
The NTP check don’t remember the peers it looks only if there is a valid peer.
If it takes to long for the new servers and you get a notification i would delay the service notification for the NTP service.
With this setting the host gets a little more time to sync to the new server.
I’ve noticed that on any system I’ve configured with some of the various NTP pool servers that the daemon on my linux systems gets various and changing NTP servers from time to time. This causes the NTP Peer service to go into an unknown state since the previous servers have gone away replaced by other servers that are served out by the pool addresses.
Is there anyway to cleanly handle this? I find that occasionally I have to re-inventory those clients to get the new Peers set and while it’s just an annoyance, if there’s a clean way to deal with it I’d like to know what that is. I could just check on the NTP Time only and not inventory each Peer but I kind of like seeing the various peers and their stats. I’ve thought about just using specific individual servers but that seems to go against the purpose of the NTP pools that are available.
I’ve run into this issue many times with pool servers. In my experience the issue is merely slow reverse dns lookups rather than anything to do with ntp itself.
You can verify this yourself by comparing the output of ‘ntpq -p -n’ which responds very quickly, vs. ‘ntpq -p’ which can be quite slow.
By default the agent does: ‘waitmax 2 ntpq -p | sed’, which only pipes the ntpq output to sed if it responds within 2 seconds, so slow dns responses will cause the check to abort and send no output. Adding -n makes that problem go away, but you get IPs instead of names in the “(synchronized on ?)” output.
You can add the -n to never do the name resolution or change it to ‘(waitmax 2 ntpq -p || waitmax 2 ntpq -p -n)’ which will get the IP’s if the names time out…
The NTP check don’t remember the peers it looks only if there is a valid peer.
If it takes to long for the new servers and you get a notification i would delay the service notification for the NTP service.
With this setting the host gets a little more time to sync to the new server.
I’ve noticed that on any system I’ve configured with some of the various NTP pool servers that the daemon on my linux systems gets various and changing NTP servers from time to time. This causes the NTP Peer service to go into an unknown state since the previous servers have gone away replaced by other servers that are served out by the pool addresses.
Is there anyway to cleanly handle this? I find that occasionally I have to re-inventory those clients to get the new Peers set and while it’s just an annoyance, if there’s a clean way to deal with it I’d like to know what that is. I could just check on the NTP Time only and not inventory each Peer but I kind of like seeing the various peers and their stats. I’ve thought about just using specific individual servers but that seems to go against the purpose of the NTP pools that are available.