New answers tagged ntp
If you want an NTP server to do anything reliably, you need not to lie to it about the reliability of its own clock; the lines server 127.127.1.0 and fudge 127.127.1.0 stratum 10 do exactly that, and it looks like getting rid of them has fixed things. As for stopping ntpd before brute-forcing the time with ntpdate, my understanding is that there's a ...
It sounds like your clock is off by more than the panic threshold. However this does not explain why multiple ntpdate invocations would fix things. To be honest I can not think of any error that would be overcome by multiple ntpdate invocations. Regardless ntpdate has been deprecated. I think that the most likely explanation is that your clock exceeds the ...
On RHEL / CentOS 6 and 7, for whatever reason ntpq tries to query the IPv6 loopback at ::1 instead of the IPv4 loopback at 127.0.0.1. With this in mind, I added this line to my /etc/ntp.conf file: restrict ::1 Saved the file then restarted ntpd (service ntpd restart) and now the command: ntpq -p works as expected. (This is the same as running ntpq in ...
The commands ntpstat and ntpq -p off-hand (from mobile so without sample output for now)
If your time is super far off Ntp will not adjust it. Stop the ntp service. Run ntpdate your.time.server and then restart the ntp service it should keep accurate time then assuming it has good access to enough time sources.
The key line here is this one: discarding peer 0: stratum=0 An NTP server identifying itself as stratum 0 is a violation of the spec (it's reserved for atomic clocks or something like that). I had this problem years ago with some BSD and Mac OS X hosts. I ended up hacking the stratum check out of the source and maintaining a separate build of the ...
Have you considered moving from NTP to PTP? http://en.wikipedia.org/wiki/Precision_Time_Protocol If you cannot move away from NTP perhaps multicasting will help. http://doc.ntp.org/4.1.1/confopt.htm Either way one of the obvious things to get right is good quality time source. Either get your own GPS receiver and/or atomic clock to your data center, or ...
As pointed out by others, a local NTP server which syncs from a public one, and provides a low latency service for your other servers will probably be the best you can do. You can get a very accurate external sync from GPS if you can see the sky, but that's often not practical. I suspect if you are having problems, you have one of two issues: Either you ...
Connecting your ntpd to NTP servers outside your LAN to time sync can lead to the inconsistencies you are seeing, because every connection will have to go thru several routers, each one with unpredictable latencies depending on traffic. If each server connects by itself, the time between all the servers will drift a little. To avoid the inconsistency, the ...
On ubuntu you should use ntpd -q instead of ntpdate if you have installed ntpd Manpage: -q Exit the ntpd just after the first time the clock is set. This behavior mimics that of the ntpdate program, which is to be retired. The -g and -x options can be used with this option. Note: The kernel time discipline is disabled with this option.
You need to stop ntpd before running ntpdate. sudo service ntp stop sudo ntpdate 0.ubuntu.pool.ntp.org sudo service ntp start
Top 50 recent answers are included