2

I have had some serious issues with time accuracy on my Ubuntu EC2 machines, with drifts of more than 60 seconds.

A possible solution is running ntpdate or ntp, but I can't get them to work on EC2:

$ sudo ntpdate ntp.nasa.gov time-b.nist.gov
23 Jun 07:17:23 ntpdate[3878]: no server suitable for synchronization found

What have I tried:

  • The ports on the specific machine I am testing are open for TCP and UDP, inbound and outbound (see below).
  • I have tested this behaviour in more than one machine.
  • I have tried different time servers.
  • I have tried both ntpdate and ntp.

Any idea how to sync the time on my machines?

Security groups

enter image description here enter image description here

Detailed logs

$ sudo ntpdate -vd ntp.nasa.gov time-b.nist.gov
23 Jun 07:24:08 ntpdate[3890]: ntpdate 4.2.6p5@1.2349-o Wed Oct  9 19:08:07 UTC 2013 (1)
Looking for host ntp.nasa.gov and service ntp
host found : ntp-nasa.arc.nasa.gov
Looking for host time-b.nist.gov and service ntp
host found : time-b.nist.gov
transmit(198.123.30.132)
transmit(129.6.15.29)
transmit(198.123.30.132)
transmit(129.6.15.29)
transmit(198.123.30.132)
transmit(129.6.15.29)
transmit(198.123.30.132)
transmit(129.6.15.29)
transmit(198.123.30.132)
transmit(129.6.15.29)
198.123.30.132: Server dropped: no data
129.6.15.29: Server dropped: no data
server 198.123.30.132, port 123
stratum 0, precision 0, leap 00, trust 000
refid [198.123.30.132], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time:    00000000.00000000  Mon, Jan  1 1900  0:00:00.000
originate timestamp: 00000000.00000000  Mon, Jan  1 1900  0:00:00.000
transmit timestamp:  d752549e.e0fc7517  Mon, Jun 23 2014  7:24:14.878
filter delay:  0.00000  0.00000  0.00000  0.00000
         0.00000  0.00000  0.00000  0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
         0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000

server 129.6.15.29, port 123
stratum 0, precision 0, leap 00, trust 000
refid [129.6.15.29], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time:    00000000.00000000  Mon, Jan  1 1900  0:00:00.000
originate timestamp: 00000000.00000000  Mon, Jan  1 1900  0:00:00.000
transmit timestamp:  d752549f.142f86b3  Mon, Jun 23 2014  7:24:15.078
filter delay:  0.00000  0.00000  0.00000  0.00000
         0.00000  0.00000  0.00000  0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
         0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000

23 Jun 07:24:17 ntpdate[3890]: no server suitable for synchronization found
5

Your security groups look like the VPC version, if that's the case I had to open UDP123/UDP* on my Network ACLs in order for it to work. VPCs have two layers of packet filtering, the Network ACL followed by the Security Groups. The SGs are STATEFUL (do not require inbound rules when connecting out first) but the NACLs are STATELESS (require rules to receive packets). Once I added the appropriate configuration line NTP worked perfectly.

I only added the line to my external NACL which run my service instances so they can access the outside NTP, they then run an NTP proxy for the rest of my network.

Good luck!

1

In EC2 the -u flag is required:

$ sudo ntpdate -u ntp.nasa.gov time-b.nist.gov
24 Jun 11:16:33 ntpdate[27714]: adjust time server 129.6.15.29 offset 0.047272 sec

From the manual:

   -u     Direct ntpdate to use an unprivileged port for outgoing packets.  This is most useful when behind a firewall that blocks incoming traffic to
          privileged ports, and you want to synchronise with hosts beyond the firewall. Note that the -d option always uses unprivileged ports.
1

Amazon provides Amazon Time Sync Service which eliminates the time drift you are experiencing. The overall steps to take on each EC2 instance are:

  1. Remove NTP using sudo apt-get remove ntp
  2. Install Chrony using sudo apt install chrony
  3. use sudo vim /etc/chrony/chrony.conf to edit the file to include server 169.254.169.123 prefer iburst
  4. Restart Chrony using sudo /etc/init.d/chrony restart
  5. Verify Chrony is using the correct IP using chronyc sources -v and verifying that the output includes '^* 169.254.169.123'
  6. Identify the best city to use by browsing the directories in ls /usr/share/zoneinfo/
  7. Update the timezone from UTC using the path from the previous step, such as sudo timedatectl set-timezone /usr/share/zoneinfo/America/Chicago

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.