Why does my ntpd not work?

Question

Edit

I've tried all your suggestions, but it seems that ntpd just refuse to synchronize to the server.

[vivs@peter-centos ~]$ /usr/sbin/ntpq -np
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================
 192.168.0.30    .LOCL.           1 u   11   64    3    0.984  232732. 20083.2

Does this jitter "20083.2" indicates the time is manually changed?

I've turned off vmware's time synchronization.

Original Question

Here is the status of ntp

[root@peter-centos gw]# /usr/sbin/ntpq -pn
 remote           refid      st t when poll reach   delay   offset  jitter
=============================================
 192.168.0.30    .LOCL.           1 u  153 1024  377    0.950  1905553 274023.
*127.127.1.0     .LOCL.          10 l    9   64  377    0.000    0.000   0.001

You can see that it only synchronize to '127.127.1.0' which is the local clock.

Is it because of the offset it too large?

But after I manually set the date by date command, it still refuse to synchronize to 192.168.0.30

This is may 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.centos.pool.ntp.org
#server 1.centos.pool.ntp.org
#server 2.centos.pool.ntp.org
server 192.168.0.30 #blf
#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

# Key file containing the keys and key identifiers used when operating
# with symmetric key cryptography.
keys /etc/ntp/keys

# Specify the key identifiers which are trusted.
#trustedkey 4 8 42

# Specify the key identifier to use with the ntpdc utility.
#requestkey 8

# Specify the key identifier to use with the ntpq utility.
#controlkey 8
lkey 8
h the ntpdc utility.
#requestkey 8

# Specify the key identifier to use with the ntpq utility.
#controlkey 8
lkey 8
olkey 8
lkey 8

Answer 1

Update, April 2021: Since at least 2016, the correct answer is to run NTP in the VMs. The below answer should be deprecated.

Previously:

Ah -- now it becomes clear:

My machine is installed in vmware workstation. So, form all the answers, I guess maybe the jitter becomes so large is because that vmware adjust the time. I will see if I am right.

Don't run ntp in a VM. The host computer doesn't guarantee CPU slices, so the VM's clock isn't accurate. As you see, ntp is trying to keep up with what looks to it like a wildly varying external clock and eventually gives up.

The general answer to this problem is to not run ntp, to install the VMware tools and lock the VM's clock to the host's clock.

The specific answer depends on the version of Linux you are running. I have some notes on CentOS (probably generally applicable to other RedHat family distributions) here.

Answer 2

First off, stop ntpd, and try to set the date using ntpdate {server}:

/etc/init.d/ntp stop
/usr/sbin/ntpdate 192.168.0.30

Does this set your time correctly? Or does it time out?

If it times out, try another NTP server:

/usr/sbin/ntpdate pool.ntp.org

From the high jitter, I would expect the ntpdate to work - once it has, reboot if possible (just restart ntpd if you can't reboot - though many services will get confused by such a time jump), and check ntpq -p again.

Answer 3

As someone mentioned above, I think the main answer is incorrect.

For VMWare, they explicitly recommend using NTP over VMWare tools in their timekeeping best practices for Linux Guests. In addition, for all VMs you should add tinker panic 0 directive to the top of the /etc/ntp.conf file to ensure that the time will correct regardless of current drift, which is common for VMs as stated.

Excerpt: Timekeeping best practices for Linux guests

NTP Recommendations

VMware recommends using NTP instead of VMware Tools periodic time synchronization. NTP is an industry standard and ensures accurate timekeeping in your guest. It may be necessary to open the firewall (UDP 123) to allow NTP traffic.

Link to full Doc: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427

Answer 4

That's a really large jitter value (274023). That indicates that you may have tried to change the time manually while ntpd was running. What you should do is stop ntpd, set the time to the correct time, and then restart ntpd.

Answer 5

VMware has best practices for Linux timekeeping:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427

Answer 6

This does it for me:

sudo service ntpd stop
sudo /usr/sbin/ntpdate 0.europe.pool.ntp.org
sudo service ntpd start

List of NTP servers:

http://www.pool.ntp.org/

For Slovenia:

http://www.pool.ntp.org/zone/si