0

I have connected a system with NTP client on a local network with windows system on which NTP server is running. The problem is client is not able to sync the time with server.

NTP version: 4.2.8p13 (on client)

NTP conf file (UPDATED):

driftfile /etc/ntp.drift
restrict -4 default
restrict -6 default
server -6 fddb::abe7:8164:14eb:2222 iburst

ntpq -npcrv result (UPDATED):

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 fddb::abe7:8164 .LOCL.           1 u    5   64    3    0.752  3925.18   1.286

associd=0 status=c016 leap_alarm, sync_unspec, 1 event, restart,
version="ntpd [email protected] Fri Mar 20 17:38:42 UTC 2020 (2)",
processor="armv7l", system="Linux/4.1.15", leap=11, stratum=16,
precision=-19, rootdelay=0.000, rootdisp=1.125, refid=INIT,
reftime=(no time),
clock=e22c442f.99e69f37  Mon, Mar 30 2020 15:40:55.601, peer=0, tc=3,
mintc=3, offset=0.000000, frequency=0.000, sys_jitter=0.000000,
clk_jitter=0.002, clk_wander=0.000

But when I update the time using ntpdate command, time gets synchronized. I have restarted the daemon many times but still the system is not syncing the time through ntpd.

Any help will be appreciated.

Thanks in Advance!

Improve this question
1
  • Found one issue: kernel logs: "ntpd[1091]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized" Do any one have idea what is it;s solution?
    – Anon
    Mar 26, 2020 at 11:45

1 Answer 1

Reset to default
1

Your time is not syncing because your clock is too far out. Your offset is 2808682 milliseconds, which is over 46 minutes. Make sure your ntpd is being started with the -G flag. (Usually -g is the default.) Alternatively, set the time to within 1 second of the correct time before starting. Then restart ntpd - your time should correct itself within a few minutes.

You also have a duplicate server line in your configuration, which is not needed, but that shouldn't be stopping things from working.

You should also remove the restrict default line, which is much too permissive and allows remote systems to query your ntpd and opens it up to being used in reflective DDOS attacks. The preferred configuration nowadays is something more like this:

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

# Needed for adding pool entries
restrict source notrap nomodify noquery

The error about the clock being unsynchronized is a symptom of this problem, not the cause.

Improve this answer
6
  • I've set the time within 1 min range and after waiting for hours it is not syncing up. Also when i execute the command ntptime it is giving return code 5. Is it affecting this mis-behaviorr in any way ?
    – Anon
    Mar 27, 2020 at 5:15
  • actually I noticed today that offset is decreasing very slowly. I've already added "iburst" in the conf file but still the sync-up is very slow
    – Anon
    Mar 27, 2020 at 7:32
  • Set the time, then gather the output of ntpq -npcrv and show your exact config file again - there might be something else you missed.
    – Paul Gear
    Mar 27, 2020 at 11:26
  • I've updated the conf file and the ntpq results in the question itself
    – Anon
    Mar 30, 2020 at 7:30
  • Your source server is synchronized to its local clock rather than a useful lower stratum source. It's likely that both it and your local clock are unstable and thus cannot usefully synchronize with each other. Get more time sources, and make sure that they have proper connections to reliable stratum 1 servers.
    – Paul Gear
    Mar 30, 2020 at 10:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .