Centos Time

Run ntpstat and see what it says.

synchronised to NTP server (173.255.219.242) at stratum 11

time correct to within 961 ms

polling server every 64 s

@lvthunder:

synchronised to NTP server (173.255.219.242) at stratum 11
You're not talking to a real server. Either your ntp.conf is wrong or you have firewall rules blocking communication.

@sweh:

@lvthunder:

synchronised to NTP server (173.255.219.242) at stratum 11
You're not talking to a real server. Either your ntp.conf is wrong or you have firewall rules blocking communication.

To expand on that, stratum 11 means you are syncing to the local clock. Allow connections to UDP destination port 123 in and out.

Check ntp.conf contains some server lines for the country your Linode is in. A driftfile is good too.

driftfile /var/lib/ntp/drift

server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org
server 3.us.pool.ntp.org

Here is my ntp.conf

# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery

# Permit all access over the loopback interface.  This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1
restrict -6 ::1

# Hosts on local network are less restricted.
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org

#broadcast 192.168.1.255 key 42         # broadcast server
#broadcastclient                        # broadcast client
#broadcast 224.0.1.1 key 42             # multicast server
#multicastclient 224.0.1.1              # multicast client
#manycastserver 239.255.254.254         # manycast server
#manycastclient 239.255.254.254 key 42  # manycast client

# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

# Drift file.  Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
driftfile /var/lib/ntp/drift

I opened the ports using these commands

iptables -I INPUT -p udp --dport 123 -j ACCEPT
iptables -I OUTPUT -p udp --dport 123 -j ACCEPT

I then turned the ntpd off and ran ntpdate 1.pool.ntp.org and got

27 Mar 16:06:37 ntpdate[11541]: step time server 94.125.129.7 offset -349.872909 sec

Now when I turn ntpd back on I get this when I run ntpstat

unsynchronised
  time server re-starting
   polling server every 64 s

Any ideas?

@lvthunder:

Any ideas?

It should be working but it can take a while to get the initial sync.

Try 'ntpq -p' and 'ntptrace'.

Darn it still says stratum 11.

ntpstat
synchronised to NTP server (149.20.68.17) at stratum 11
   time correct to within 950 ms
   polling server every 64 s

ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+ntp1.Housing.Be 128.32.206.55    3 u    8   64  177    3.320  -346373   8.795
+zulu.frizzen.ne 209.151.225.100  3 u    2   64  177   16.902  -346390  14.014
*pool-test.ntp.o 66.220.9.122     2 u   33   64   77    1.256  -346375   6.932
 LOCAL(0)        .LOCL.          10 l   44   64   77    0.000    0.000   0.001

ntptrace
localhost.localdomain: stratum 11, offset 0.000000, synch distance 0.950956
pool-test.ntp.org: stratum 2, offset -0.000014, synch distance 0.000574
clock.fmt.he.net: stratum 1, offset 0.000001, synch distance 0.000258, refid 'CDMA'

Your offset is ludicrous!

Stop NTP, run 'ntpdate pool-test.ntp.org', then start NTP. Then wait for 30 minutes and it should be OK.

Also, comment out this:

server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

That generally shouldn't be used in an Internet-connected environment.

I commented those lines out and now a couple hours later it is saying

unsynchronised
   polling server every 64 s

Is there a way to test the iptables settings?

Did you restart NTP after making the configuration change? What does ntpq -p report now?

Edit: As for iptables, your earlier ntpq -p proves that your firewall is not causing problems for NTP.

Yes I am pretty sure I restarted it. To be really sure I'll do it again.

Here is ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*216.45.57.38    204.123.2.5      2 u   10   64   37    9.390  -341845   6.877
+stratum2-2.NTP. 129.70.130.70    2 u   12   64   37  172.813  -341852   9.777
 209.141.38.41   216.218.254.202  2 u   60   64   17   17.364  -341840   5.293

You didn't run the ntpdate command because your machine is still massively wrong.

You need to get it "close to right" before running ntpd. "ntpdate" will change your clock to be "close to right" and then ntpd can keep it right.

When I run ntpdate I get this.

29 Mar 10:10:56 ntpdate[17953]: step time server 149.20.68.17 offset -341.469929 sec

Does that mean it worked or failed???

Is it so far off that i need to manually set the time?

Now what happens if you restart ntpd, wait 30 minutes and then run ntpstat and friends?

ntpstat

unsynchronised
   polling server every 64 s

ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+bindcat.fhsu.ed 128.138.140.44   2 u   30   64  377   50.756  -341312   9.169
+kona.skafari.co 18.26.4.105      2 u   19   64  377   74.019  -341308   8.947
*173.244.211.10\. 204.42.158.152   2 u    6   64  377   20.553  -341305  10.665

ntptrace

localhost.localdomain: stratum 16, offset 0.000000, synch distance 0.010680

Thanks everyone for all your help. It seems to me this shouldn't be that difficult.

This doesn't make any sense. It looks like ntpdate isn't actually setting the time.

If you have followed the instructions in this thread it should have worked. All I can suggest is stop ntp, check it's stopped, run ntpdate at least 3 times and check it says there is a tiny offset the last time, then restart ntp. Then wait 30 minutes.

If that doesn't work open a support ticket.

I'll open a ticket. The offset is still -341.1 something. Thanks everyone for your help.

This is what they said.

Thank you for the update. As you are running a legacy kernel your time is bound to the host's clock. I suggest adjusting your Linode's configuration profile to use our latest 3.x kernel then rebooting. If you wish to continue using a legacy kernel you can uncouple your clock from the host with the following command -

"echo 1 > /proc/sys/xen/independent_wallclock"

If you want this to persist through reboots you will need to adjust sysctl.conf appropriately -

xen.independent_wallclock=1

If you have any other questions please let us know.

So I'm updating the kernel. Now the second time I ran ntpdate the offset was -0.000216. So I think it's fixed now. Thanks.

Which leaves 2 questions:

Why is the host's clock so far out?

Why are you using a really old kernel?

1. I don't know. I didn't ask.

2. I didn't know you were suppose to go change it. When I was doing updates I kept seeing kernel updates. So I didn't know I was using an old one. This is my first VPS.