0

we have 3 machines in the cluster ( redhat 7.2 )

  • linux_machine1
  • linux_machine2
  • linux_machine3

the machines time are like this

Sun Sep  1 13:54:20 UTC 2019 - linux_machine1
Sun Sep  1 13:34:15 UTC 2019 - linux_machine2
Sun Sep  1 13:53:35 UTC 2019 - linux_machine3

we can see time diff between machines ( this isnt good because all machines should be sync to ntp server name moon.ntp.org )

the configuration file:

more /etc/chrony.conf
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server name moon.ntp.org iburst

we check also the chronyd service , and service is running on all machines

systemctl status chronyd

we checked also the 

chronyc tracking | grep "Leap status"
Leap status     : Normal

And we get normal state on all machines

So if configuration is ok ( moon.ntp.org is the ntp server ) And Leap status is Normal

And all services are running

Then why we get the gap on time on all 3 Linux servers ?

UPDATE:

after we restart all chrony service as

systemctl restart chronyd

now the time on all machines is equal

the question is - why need here chronyd restart ?

Paul Gear
  • 4,367
  • 19
  • 38
shalom
  • 461
  • 13
  • 29
  • Did you change anything in the config or anything bit references after starting the `chronyd` service the first time? – Nasir Riley Sep 02 '19 at 22:22
  • 1
    What is `moon.ntp.org` ? I can find no public reference to it, which I would expect for something from ntp.org. If this is made up or obfuscated, please use `example.org` or some other rfc2606 compliant example. – John Mahowald Sep 03 '19 at 02:30
  • moon.ntp.org ןis the ntp server , we want to sync to this machine – shalom Sep 03 '19 at 04:36
  • "Did you change anything in the config or anything bit references after starting the chronyd" - NO – shalom Sep 03 '19 at 04:37
  • I can't resolve `moon.ntp.org` either. You should try an ntp server that actually exists. – Gerald Schneider Sep 03 '19 at 06:30
  • moon.ntp.org its just host example , the real example is configured , I can view it because security – shalom Sep 03 '19 at 06:32
  • Please show the full output of `chronyc -n sources` and `chronyc -n tracking` for all hosts. – Paul Gear Sep 03 '19 at 21:32
  • Also, the correct syntax in `chrony.conf` is `server host1.example.org iburst`, not `server name host1.example.org iburst`. – Paul Gear Sep 03 '19 at 21:33
  • May not solve issue, but why not have 'machine1' update off of the 'moon host', then have the other 2 machines (or more) update from machine1? (Especially if on same LAN segment). In other words not every machine has to reach out to 1 specific public host for an update. Keep it as local as possible is always best rule of thumb. I use ntpd on my router and update all machines on my LAN from it. (for instance).. – B. Shea Sep 07 '19 at 00:53
  • @bshea That is bad advice from the perspective of both accuracy and redundancy. NTP uses time metrics from multiple sources to ensure minimum offsets, so there should be no choke points in an NTP setup (i.e. single-host strata, where all downstream NTP systems are dependent on one system's clock). – Paul Gear Sep 08 '19 at 21:31
  • @PaulGear - I will admit it creates one point of failure. I should have mentioned that. But, accuracy? I disagree. If public facing ntpd server is working correctly (using multiple ntp sources / pool) the accuracy is fine for all ntp clients using it for updates across a given network. Maybe not mission critical time needs, but those who need super accurate time across a network normally run multiple ntp servers themselves as well. (stratum 0(s) or multiple stratum 1's). – B. Shea Sep 09 '19 at 15:58
  • For a general 'all purpose' network|machines (as apparently the OP has) the method I mention is more than adequate. If you have only 1 router that cannot access Internet then certainly no amount of multiple NTP client (or server) connections to outside riding under it will be able either. Still a single point of failure. – B. Shea Sep 09 '19 at 16:19
  • @bshea If you don't agree that choke points compromise NTP's accuracy, then you are mistaken about how it works. Specifically, the selection (intersection) and clustering algorithms are null when working with only one source. For more, see http://doc.ntp.org/current-stable/warp.html#arch, my summaries at https://is.gd/xW2qbb and https://is.gd/nZZpT2, and the NTP BCP RFC at https://tools.ietf.org/html/rfc8633 – Paul Gear Sep 10 '19 at 20:34
  • I did not say that. I am well aware of best practices. Repeat: Unless your stuff is mission critical re: time it's overkill. I've run NTP for 20+ years on servers / networks and my system clocks have never been off by any degree. My writes are synced fine across network and accurate - which I've tested. Why wouldn't they be? They sync from same local source - my router - which syncs from pooled sources. And yeah here ya go: https://tools.ietf.org/html/draft-ietf-ntp-bcp-13#section-3.2 ALERT! USE 3 OR MORE SERVERS IF YOU NEED SUPER-ACCURATE TIME!! We done now? – B. Shea Sep 11 '19 at 00:49

0 Answers0