0

I am configuring a NTP server to synchronize the time on the both systems, Linux and Windows. I'm using CentOS 7 and Windows Server 2012.

In /etc/ntp.conf, I set the Windows Server IP address instead of the defaults.

#server 0.centos.pool.ntp.org iburst
#server 1.centos.pool.ntp.org iburst
#server 2.centos.pool.ntp.org iburst
#server 3.centos.pool.ntp.org iburst
server example.com

Therefore, I input ntpq -p, but it seems not working well. In refid column, there is no IP address and I can't see * as well. Even the time is not same in the both systems.

[root@ ~]# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 example.com      .LOCL.           1 u    3   64  377    1.056  5760156   6.457

Meaning, I guess the above result should(?) or must be shown as following, doesn't it?

[root@ ~]# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*example.com      192.168.x.x      1 u    3   64  377    1.056  5760156   6.457

What do I need to do to fix? When I stop ntpd and input ntpdate example.com, it seems that synchronization works. I can get the correct time. Is it fine with this??

Additionally, I can't see any ntp config in chkconfig --list. Is it ok?

[root@ ~]# chkconfig --list

Note: This output shows SysV services only and does not include native ...

jexec           0:off   1:on    2:on    3:on    4:on    5:on    6:off
netconsole      0:off   1:off   2:off   3:off   4:off   5:off   6:off
network         0:off   1:off   2:on    3:on    4:on    5:on    6:off
0

In "refid" column, there is no IP address

It doesn't have to be an IP. The column just shows what the system is using as its clock source. If it's another NTP server, it will be an IP. But for systems with a local clock source, it can be something else. .LOCL. just means the system is using the local clock as a source. This isn't normally recommended except as a fallback, because there's usually no synchronization to keep it correct.

This particular clock is offset from yours by 96 minutes.

Because the clock isn't close, the daemon may be waiting a while to trust the source. After a while it should shift the clock. It should do this immediately if you add the iburst keyword to the server line (and start the daemon with the -g option to allow it to sync when out by more than 1000s).

  • Also, 96 minutes may take a while to correct. Better to step the time with ntpdate before starting the ntpd daemon. – Kusalananda Jun 25 '18 at 5:38
  • That's exactly same with what I've done. Thank you so much guys! :) – owcred601 Jun 25 '18 at 6:23

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.