One of the workaround for old CentOS/CentOS kernel (6.1-6.3) which may "Systems hang due to leap-second livelock." (quoting redhat ), is to set tinker step in /etc/ntp.conf. Bug the documentation is not clear about the unit/syntax (). What is the exact syntax (unit) for tinker step? Also, how can I query the current value of tinker step on a running NTP daemon?

I am currently experiencing incredibly long sync delays with ntpd and, after much Googling, have decided to start a fresh thread as all 'remedies' have failed to work. The machine in question is a Raspberry Pi 3B running Raspi OS 'Buster' (the 5/7/21 lite/non-GUI image). As it is to be the head node for a small cluster, it has 2 NICs - eth0 (built-in NIC and inside interface) is set to 192.168.4.100/24 and eth1 (USB dongle and outside interface) is set to 192.168.1.220/24. I am currently using dhcpcd to configure the interfaces and have name servers defined in /etc/resolvconf.conf. ntpd **will** eventually sync up, but only after hours and when I reboot the Pi, despite the fake-hwclock saving the time in /etc/fake-hwclock.data, ntpd is back at square one and starts the hours-long sync process again. I should note that the time saved in /etc/fake-hwclock is UTC time, not time zone adjusted time, but I wouldn't think that that would affect ntpd's sync time. Below is my /etc/ntp.conf file. Uncommenting the 'tinker panic 0' line does not seem to affect synchronization at all. To summarize, my questions are: 1) How can I reduce the sync time delay? 2) If I reboot the Pi after ntpd has sync'ed, running the 'date' command will give me the proper time, BUT ntpd will have returned to square one and it will take hours for it to sync. How can this be avoided? (Logic says that it shouldn't take very long to reconcile the local and remote times when they are mere seconds apart) systemd-timesyncd is **disabled**. ------- /etc/ntp.conf

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

#tinker panic 0

driftfile /var/lib/ntp/ntp.drift

# Leap seconds definition provided by tzdata
leapfile /usr/share/zoneinfo/leap-seconds.list

# Enable this if you want statistics to be logged.
#statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

# You do need to talk to an NTP server or two (or three).

server time-a-g.nist.gov iburst
server time-a-wwv.nist.gov iburst

server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst

# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details.  The web page 
# might also be helpful.
#
# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery limited

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

# Needed for adding pool entries
restrict source notrap nomodify noquery

# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)

broadcast 192.168.4.255

Output of 'uptime' and 'ntpq -p' at 11:07 AM CDT (according to my MacBook Pro's clock):

charles@Chimera-Head-Node:~ $ uptime
 10:12:52 up 34 min,  1 user,  load average: 0.00, 0.00, 0.00
charles@Chimera-Head-Node:~ $ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 192.168.4.255   .XFAC.          16 B    -   64    0    0.000    0.000   0.002
 time-a-g.nist.g .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 time-a-wwv.nist .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 ec.sedley.net   .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 ntp1.doctor.com .INIT.          16 u    - 1024    0    0.000    0.000   0.000

Note: Whenever I boot/reboot the Pi, the broadcast address always shows up as .XFAC. for the refid. If I do a simple 'sudo service ntp restart', the refid changes to .BCST. (what it needs to be). I've yet to fix that problem and while it is an issue for another thread, any suggestions are welcome :-) Output of syslog on boot (non-ntpd/dhcpcd entries removed):

Sep  1 09:38:53 Chimera-Head-Node ntpd: ntpd 4.2.8p12@1.3728-o (1): Starting
Sep  1 09:38:53 Chimera-Head-Node ntpd: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 109:114
Sep  1 09:38:53 Chimera-Head-Node systemd: Started Network Time Service.
Sep  1 09:38:53 Chimera-Head-Node ntpd: proto: precision = 1.458 usec (-19)
Sep  1 09:38:53 Chimera-Head-Node ntpd: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): good hash s
ignature
Sep  1 09:38:53 Chimera-Head-Node ntpd: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): loaded, exp
ire=2021-12-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37
Sep  1 09:38:53 Chimera-Head-Node ntpd: Listen and drop on 0 v6wildcard [::]:123
Sep  1 09:38:53 Chimera-Head-Node ntpd: Listen and drop on 1 v4wildcard 0.0.0.0:123
Sep  1 09:38:53 Chimera-Head-Node ntpd: Listen normally on 2 lo 127.0.0.1:123
Sep  1 09:38:53 Chimera-Head-Node ntpd: Listen normally on 3 eth1 192.168.1.220:123
Sep  1 09:38:53 Chimera-Head-Node ntpd: Listen normally on 4 lo [::1]:123
Sep  1 09:38:53 Chimera-Head-Node ntpd: Listen normally on 5 eth0 [fe80::ba27:ebff:fed5:8e4d%2]:123
Sep  1 09:38:53 Chimera-Head-Node ntpd: Listen normally on 6 eth1 [fe80::1f2d:3bb6:af44:5cbb%3]:123
Sep  1 09:38:53 Chimera-Head-Node ntpd: Listening on routing socket on fd #23 for interface updates
Sep  1 09:38:53 Chimera-Head-Node ntpd: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Sep  1 09:38:53 Chimera-Head-Node ntpd: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Sep  1 09:38:54 Chimera-Head-Node dhcpcd: eth0: using static address 192.168.4.100/24
Sep  1 09:38:54 Chimera-Head-Node dhcpcd: eth0: adding route to 192.168.4.0/24
Sep  1 09:38:55 Chimera-Head-Node ntpd: Listen normally on 7 eth0 192.168.4.100:123
Sep  1 09:38:55 Chimera-Head-Node ntpd: 192.168.4.255 local addr 192.168.1.220 -> 192.168.4.100
Sep  1 09:38:55 Chimera-Head-Node ntpd: new interface(s) found: waking up resolver
Sep  1 09:39:01 Chimera-Head-Node dhcpcd: eth1: no IPv6 Routers available
Sep  1 09:39:03 Chimera-Head-Node dhcpcd: eth0: no IPv6 Routers available

What are expected values for offset and jitter from NTP? I have Solaris 11.4 in a VM with NTP configured and am comparing Solaris time stats to my Mac. I notice that MacOS sntp -sS time.apple.com reports very low offset of ~0.01s +/- ~0.01s. On Solaris I invoke ntpq -pcrv and note my offset is ~-6s +/- ~2s to time.nist.gov.

We have some embedded devices using ntpd(4.2.8p10) to sync the time. One of our customers is using their own ntp server inside an internal network. From the ntpd -dgq debug mode, we found the server is reachable and we can get the offset, delay and jitter info. However, the ntpd will only exit with"**ntpd: no servers found**" and never select and set the local time.

2 Nov 11:57:05 ntpd: ntpd 4.2.8p10@1.3728-o Thu Jul 26 19:52:20 UTC 2018 (2): Starting
2 Nov 11:57:05 ntpd: Command line: ntpd -dgq
2 Nov 11:57:05 ntpd: proto: precision = 2.000 usec (-19)
Finished Parsing!!
restrict: op 1 addr 0.0.0.0 mask 0.0.0.0 mflags 00000000 flags 000005f0
restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 00000000 flags 00000000
restrict source template mflags 4000 flags 1c0
restrict: op 1 addr (null) mask (null) mflags 00004000 flags 000001c0
move_fd: estimated max descriptors: 1024, initial socket boundary: 16
2 Nov 11:57:05 ntpd: Listen and drop on 0 v4wildcard 0.0.0.0:123
2 Nov 11:57:05 ntpd: Listen normally on 1 lo 127.0.0.1:123
restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 00003000 flags 00000001
2 Nov 11:57:05 ntpd: Listen normally on 2 eth1 192.168.168.109:123
restrict: op 1 addr 192.168.168.109 mask 255.255.255.255 mflags 00003000 flags 00000001
2 Nov 11:57:05 ntpd: Listen normally on 3 wlan0 192.168.100.1:123
restrict: op 1 addr 192.168.100.1 mask 255.255.255.255 mflags 00003000 flags 00000001
2 Nov 11:57:05 ntpd: Listening on routing socket on fd #27 for interface updates
key_expire: at 0 associd 60163
peer_clear: at 0 next 1 associd 60163 refid INIT
restrict: op 1 addr 10.160.129.161 mask 255.255.255.255 mflags 00004000 flags 000001c0
restrict_source: 10.160.129.161 host restriction added
event at 0 10.160.129.161 8011 81 mobilize assoc 60163
newpeer: 192.168.168.109->10.160.129.161 mode 3 vers 4 poll 6 10 flags 0x101 0x1 ttl 0 key 00000000
event at 0 0.0.0.0 c016 06 restart
peer_xmit: at 1 192.168.168.109->10.160.129.161 mode 3 len 48 xmt 0xe52bde52.ddf3c87c
auth_agekeys: at 1 keys 0 expired 0
event at 1 10.160.129.161 8014 84 reachable
clock_filter: n 1 off 30.082946 del 0.048598 dsp 7.945314 jit 0.000002
peer_xmit: at 3 192.168.168.109->10.160.129.161 mode 3 len 48 xmt 0xe52bde54.ddf0a416
clock_filter: n 2 off 30.083616 del 0.047583 dsp 3.949228 jit 0.000670
peer_xmit: at 5 192.168.168.109->10.160.129.161 mode 3 len 48 xmt 0xe52bde56.dde968ab
clock_filter: n 3 off 30.078398 del 0.054469 dsp 1.951189 jit 0.004895
peer_xmit: at 7 192.168.168.109->10.160.129.161 mode 3 len 48 xmt 0xe52bde58.dde80026
clock_filter: n 4 off 30.079499 del 0.074539 dsp 0.952172 jit 0.003164
peer_xmit: at 9 192.168.168.109->10.160.129.161 mode 3 len 48 xmt 0xe52bde5a.ddea03c8
clock_filter: n 5 off 30.083616 del 0.044472 dsp 0.452664 jit 0.003340
2 Nov 11:57:16 ntpd: ntpd: no servers found
END OF FILE

Also, when running ntpd in the background and using **ntpq -p** to query the ntpd status. We get the following result, the st, delay, offset and reach seem fine.

root@S8P20092901:~# ntpq -c as

ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 59609  9014   yes   yes  none    reject   reachable  1

root@S8P20092901:~# ntpq -np
     remote           refid      st t when poll reach   delay    offset  jitter
==============================================================================
 10.160.129.161  162.159.200.123  4 u  24   64   377    40.404    -180.122   20.122

However, the ntpd never select the ntp server as the time source(never show "*" or "+" before the remote address ) or sets the local time after a long time of waiting.
I looked into the source code. When using ntpdate(-q) mode the ntpd will exit after doing all bursts for every server when there is no clock selected/ set

} else {
		peer->burst--;
		if (peer->burst == 0) {

			/*
			 * If ntpdate mode and the clock has not been
			 * set and all peers have completed the burst,
			 * we declare a successful failure.
			 */
			if (mode_ntpdate) {
				peer_ntpdate--;
				if (peer_ntpdate == 0) {
					msyslog(LOG_NOTICE,
					    "ntpd: no servers found");
					if (!msyslog_term)
						printf(
						    "ntpd: no servers found\n");
					exit (0);
				}
			}
		}
	}

However, I am still not understand why ntpd didn't select and set a time form the server. Thanks for your help in advance.

there are so many tutorials out there explaining how to setup dhcpd server, in relation to providing ntp suggestions to dhcp clients, that I had always thought that ntp configuration was carried out automatically. Recently I started seeing clock drifts in my local network, so I assume this was a wrong assumption. So I set out to see how can one minimize the ntp client configuration, provided one has carried out the effort to set up ntp-server suggestions through dhcpd. I have not been able to find much apart from this Ubuntu specific help tutorial https://help.ubuntu.com/community/UbuntuTime . Even here (see paragraph under "Troubleshooting -> Which configuration file is it using?") the information is scarce but it says that if an /etc/ntp.conf.dhcp file is found it will be used instead. First of all the actual location that the writer meant here is /var/lib/ntp/ntp.conf.dhcp as observed in /etc/init.d/ntp , but regardless of that the presence of this file does not guarantee that the ntp will request servers from dhclient. As a result, I have to explicitly add the server clause in ntp.conf.dhcp for my local ntp server. But in that case, why do I even setup ntp settings on the dhcpd server? This seems to go against intuition, ie setup ntp settings once (ie on the server) and let dhcpd server delegate the information to the clients. How can I minimize (if not avoid altogether), client configuration for the ntp. Alternatively, how can I get ntp information through dhclient. Is there a cli solution that fits all linux distros? I assume every client should have the executables of ntpd, but I do not know how to proceed from there. Thank you EDIT: ubuntu client verbose output when running manually dhclient: sudo dhclient -1 -d -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0 Internet Systems Consortium DHCP Client 4.2.4 Copyright 2004-2012 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/eth0/20:cf:30:0e:6c:12 Sending on LPF/eth0/20:cf:30:0e:6c:12 Sending on Socket/fallback DHCPREQUEST of 192.168.112.150 on eth0 to 255.255.255.255 port 67 (xid=0x2e844b8f) DHCPACK of 192.168.112.150 from 192.168.112.112 reload: Unknown instance: invoke-rc.d: initscript smbd, action "reload" failed. RTNETLINK answers: File exists * Stopping NTP server ntpd ...done. * Starting NTP server ntpd ...done. bound to 192.168.112.150 -- renewal in 41963 seconds. The ntpd service is restarted, yet running ntpq -cpe -cas afterwards I still do not see my local ntp server in the list of ntp servers. Of course my dhcpd server does have option ntp-servers subnet 192.168.112.0 netmask 255.255.255.0 { max-lease-time 604800; default-lease-time 86400; authoritative; ignore client-updates; option ntp-servers 192.168.112.112; #self ... (many other options) }

I realize that Microsoft doesn't even recommend using a windows server as a time service, however I don't have a choice -- closed network in a windows centric shop. It became an issue when the newer Solaris 11 systems could not sync to the AD servers which come with NTP v4 ( 4.2.8p10 ). It does work for the Solaris 10 servers using the older v3 (xntpd) as a client. I tried disabling the older client, and enabling the ntp4 client ( 4.2.8p9) on the Solaris 10 systems. So even though it had been working, and uses the same ntp.conf, the v4 client fails to sync. Anyone have any suggestions on a possible tweak to sync a NTP v4 client to a Windows 2012 R2 AD server? **ntp.conf** server AD_SVR1_IP prefer iburst server AD_SVR2_IP peer rac-node2 My long term plan is to get the network team to enable a NTP service on one of their device that we all point to. Thanks

The situation: - We have some Linux VMs running compute jobs. - The VMs do not have Internet access (including NTP). - The hypervisor does know the correct time. - The hypervisor's time is exposed to the VM via its hardware clock. - The hypervisor seems to be QEMU/KVM-based. We do not control the hypervisor (it is a cloud VPS offering). The problem: - The VMs' system clock drifts away from the correct time / hardware clock. The question: - Is it possible to keep the system clock synchronized to the hardware clock at all times? - Alternatively, is it possible to tell e.g. ntpd to account for system clock drift, using the hardware clock as reference? What I tried: - A 0 * * * * hwclock --hctosys cronjob, however, the drift is significant enough that even hourly synchronization is insufficient, and increasing the cronjob frequency seems like a workaround at this point.

I'm playing with containerizing various parts of my server infrastructure and one of the services I would like to run in container is ntp daemon. I'm using systemd-nspawn (systemd 233) as a hypervisor as well as init process inside of the containers. ntpd version is 4.2.8p10. Every time I try to start ntpd inside of a container it crashes with cap_set_proc() operation not permitted error: 21 Oct 11:10:23 ntpd: ntpd 4.2.8p10@1.3728 Fri Oct 20 23:28:39 UTC 2017 (1): Starting 21 Oct 11:10:23 ntpd: Command line: ntpd -g -n -u ntp:ntp 21 Oct 11:10:23 ntpd: Cannot set RLIMIT_MEMLOCK: Operation not permitted 21 Oct 11:10:23 ntpd: proto: precision = 0.335 usec (-21) 21 Oct 11:10:23 ntpd: Listen normally on 0 v4wildcard 0.0.0.0:123 21 Oct 11:10:23 ntpd: Listen normally on 1 lo 127.0.0.1:123 21 Oct 11:10:23 ntpd: Listening on routing socket on fd #18 for interface updates 21 Oct 11:10:23 ntpd: mlockall(): Cannot allocate memory 21 Oct 11:10:23 ntpd: start_kern_loop: ntp_loopfilter.c line 1119: ntp_adjtime: Operation not permitted 21 Oct 11:10:23 ntpd: set_freq: ntp_loopfilter.c line 1082: ntp_adjtime: Operation not permitted 21 Oct 11:10:23 ntpd: cap_set_proc() failed to drop root privs: Operation not permitted What I have tried so far: 1. Building ntpd without capabilities enabled - it starts properly, but still has same ntp_adjtime syscall permission issues. 2. Running systemd-nspawn with --private-users=0 and without --private-users at all. 3. Playing with capabilities for systemd-nspawn itself (mainly CAP_SYS_TIME and CAP_NET_BIND_SERVICE) 4. Playing with capabilities for ntpd inside of the container. All this gave no positive results and I wonder what am I missing. Any ideas will be greatly appreciated.

When I query the status of the NTP daemon with ntpdc -c sysinfo I get the following output: system peer: 0.0.0.0 system peer mode: unspec leap indicator: 11 stratum: 16 precision: -20 root distance: 0.00000 s root dispersion: 12.77106 s reference ID: [73.78.73.84] reference time: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000 system flags: auth monitor ntp kernel stats jitter: 0.000000 s stability: 0.000 ppm broadcastdelay: 0.000000 s authdelay: 0.000000 s This indicates that the NTP sync failed. However the system time is accurate within 1 second precision. When I ran my system without network connection for the same period as I did now the system time would deviate ~10s. This behavior suggests that the system has another way of syncing the time. I realized that there is also systemd-timesyncd.service (with configuration file at /etc/systemd/timesyncd.conf) and timedatectl status gives me the correct time: Local time: Thu 2016-08-25 10:55:23 CEST Universal time: Thu 2016-08-25 08:55:23 UTC RTC time: Thu 2016-08-25 08:55:22 Time zone: Europe/Berlin (CEST, +0200) NTP enabled: yes NTP synchronized: yes RTC in local TZ: no DST active: yes Last DST change: DST began at Sun 2016-03-27 01:59:59 CET Sun 2016-03-27 03:00:00 CEST Next DST change: DST ends (the clock jumps one hour backwards) at Sun 2016-10-30 02:59:59 CEST Sun 2016-10-30 02:00:00 CET So my question is what is the difference between the two mechanisms? Is one of them deprecated? Can they be used in parallel? Which one should I trust when I want to query the NTP sync status? (Note that I have a different system (in a different network) for which both methods indicate success and yield the correct time.)

I want to create a NTP server, and my clients could sync date from this Server. So I add restrict policy in my server, and then restart the NTP service to my it works as a NTP server. Then I add this server to my clients, and remote other NTP servers and pools to make it the only NTP server in this client. I have already run this command to check this server chosen by the client:

ntpq -pn

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*xx.xx.xx.xx     91.189.91.157    3 u  342   64  340    0.087    8.349 4492269

As you can see, it works fine. I also run **ntpdate -q xx.xx.xx.xx** to check the time by hand. But I want to change a specific time in my NTP server, so I disabled all the pools in my NTP Server, and then using **date -s** to change the time. I also restarted this Server. The problem is that when I finished all these steps, the client cannot sync the datetime from my NTP server!

ntpdate -q xx.xx.xx.xx
server xx.xx.xx.xx, stratum 16, offset -26584.931234, delay 0.02574
27 Aug 07:23:49 ntpdate: no server suitable for synchronization found

Does that mean I still need to define a pool or a server in my NTP server, and how could I change a specific time in my NTP server?

I have a home server which runs an up to date Debian 7.5 (wheezy) installation. I just discovered that the server has its internal clock set to ± 3 minutes *in the future*. I knew that I could use NTP to synchronize Debian (and the motherboard internal clock) with NTP, so I installed NTP by following the steps described in the french Debian Wiki (the English page is less detailed). I used the following command to sync the internal clock:

ntpdate -B -q 192.168.0.254

The clock was successfully adjusted. But this is a temporary solution, so I installed the NTP daemon and added a local server in the /etc/ntp.conf file:

# pool.ntp.org maps to about 1000 low-stratum NTP servers.  Your server will
# pick a different set every time it starts up.  Please consider joining the
# pool: 

# added
server 192.168.0.254

server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst

Is it the right solution? In fact I was surprised to find that the ntp daemon wasn't already installed. I'm wondering if the default installation of Debian installs a daemon to keep the internal clock synchronized. Are all the Debian installations time-shifting until their admins install ntpd? Please tell me that the ntp daemon won't be useless because Debian has a built-in synchronization mechanism.

I want to get rid of all ntpd related stuff from my yocto linux image. Currently I include the meta-openembedded layer, which is responsible that the NTP service ntpd is installed on my final image. Since I don't need it and want to keep my image as small as possible, I would like to know how I can remove it with my own recipe without messing around with the meta-openembedded layer. I tried to create a recipe recipes-support/ntp/ntp_%.bbappend recipe in which I set the follwing: FILESEXTRAPATHS:prepend := "${THISDIR}/${BPN}:" CONFIG_NTPD = "n" But this does not seem to work. So my question would be how I can deactivate a recipe with another recipe or exclude it from the final image. I have also tried it from a python() {} or do_install:append() block with d.setVar("CONFIG_NTPD", "n") but also without success. This would even have the charming advantage that I could link the removal of the NTP packets to another variable.

I have recently been doing a specific timing analysis of the performance of NTP under controlled conditions.  The experiment I performed was conceptually quite simple.  I have an NTP server running somewhere on my network (this is my own server with its own integrated GPS receiver). - on a specific machine, I turn off the NTP client - I manually offset the machine's system time by *N* ms (where I tried *N* = 50 ms and 500 ms) - at once, I turn on the machine's NTP client - and I monitor the behavior of the machine's system time to see how it brings the system time back in synch with NTP time. - Finally, I repeat the above operations LOTS (hundreds) of times to get good statistics on that. To answer one of the comments here, I make it clear that the utility acting as ntp client is: chronyd and the utility acting as ntp server is whatever program is running on the NTP server hardware : SyncServer S600 . Here's what I observed.  First, the NTP client takes 5 seconds of "thinking" before it does anything.  Then, once it starts acting on the machine's system time, it adjusts that system time continuously at a rate of 100 ms per second (in other words, if the offset between the machine's system time and the NTP time was 500 ms, it takes 5 seconds to bring that offset back down close to 0 ms). This behavior is visible in the attached plot: SO, as a non-NTP expert, I wonder: - where are the settings/configuration for NTP to behave in that manner? - specifically, what is it doing for those 5 seconds of waiting? - where is the configuration for that slew rate of 100 ms per second? - Finally, not shown in here, but somehow, NTP actually changes the drift rate or the frequency of the system clock.  I know this because, after having left NTP on for some time, if I turn it off, then the drift between the system time and the NTP time remains almost zero (or very low), at least much much lower than if I had just rebooted that machine from scratch. So there is some information of the adjustment done by NTP that remains locked in the system time even after turning NTP off. Where and how is that done? I realise that's a few different questions, but I'm trying to dig deeper to understand the behavior of NTP, and if all of those are hardwired in the server (or client) or if those are configuration changeable.

**How can I get detailed information about the NTP status of my system, when using systemd-timesyncd as the time client?** The closest one I found is # timedatectl status Local time: Wed 2019-06-05 09:03:09 CEST Universal time: Wed 2019-06-05 07:03:09 UTC RTC time: Wed 2019-06-05 07:03:09 Time zone: Europe/Paris (CEST, +0200) System clock synchronized: no systemd-timesyncd.service active: yes RTC in local TZ: no but this only gives me very general information. Specifically, there is no information about which peers I am connected to, the delay/drift etc. How can I get the information I would be normally getting via ntpq if using ntpd (or chrony)

I'm working on a C application that requires NTP time to be synchronized on the host before proceeding. I've essentially written a wrapper C function that executes the command ntpq -p If the output contains the * character, I consider that be connected and ready to proceed. An example output where NTP is successfully synchronized : remote refid st t when poll reach delay offset jitter ============================================================================== *myserver.domain.com xxx.xxx.xxx.xxx 2 u 729 1024 377 1.120 -1.834 2.282 If the output **DOES NOT** contain the * character, my program goes to sleep for a second and then checks again. This process repeats until the * character is found. However, I've noticed on one of my machines the * character takes a long time to finally show up (~5 minutes) after a reboot. Yet it seems to have been synchronized successfully much sooner. In other words, when I issue a datetime, it shows a seemingly correct time that must have been grabbed from the NTP server yet the * character does not appear until minutes later. This negatively affects my application because it essentially cannot run for 5 minutes after a system restart. I use the 'iburst' option in my ntp.conf file hoping that it would synchronize things quickly. # my NTP server config server myserver.domain.com iburst Again, IT DOES seem to synchronize fast, yet the ntp -q output takes a while until it reports the * character. Any idea on how I can resolve this behavior? Additionally - is there a better command for checking if the NTP synchronization has been completed? **Edit #1: Adding some more info** I've learned from Chris Davies response that ntpd requires 8 successful polls before it is considered synchronized. This explains why my clock is seemingly correct even though it isn't synchronized. What DOES NOT make sense is why its polling on start-up so slowly, even though I have the iburst option set. I'm noticing that the refid = .STEP. on initial startup. I'm not sure if this relevant since it just means the initial synchronization was very large. **Edit #2: Here is the full sequence** 1. Host boots up - it appears that initial NTP sync occurs and the change is very large hence refid = .STEP. 2. After a while, refid updates the IP address of my NTP server. However, it's still considered unsynchronized because 8 consecutive successes have not occurs. And it's only polling every 64 seconds hence the long sync time. NOTE: I DO HAVE IBURST ENABLED THOUGH!!! 3. If I restart the NTP daemon service, it comes back up and synchronizes immediately. As if iburst is now working fine. 4. It's almost as if the iburst option is failing when NTP daemon starts after a reboot. But then works fine if the service is restarted.

I need to create device (currently Raspberry Pi 3 based) which states as NTP Server, it has no connection to Internet and NTP should read actual time from local system clock (this clock is set from application). My /etc/ntp.conf is: restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery restrict 127.0.0.1 restrict -6 ::1 restrict ::1 server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 1 driftfile /var/lib/ntp/ntp.drift logfile /var/log/ntp.log When testing connection (after service ntp restart) with ntpdate -du localhost command I get this output: transmit(::1) receive(::1) transmit(127.0.0.1) receive(127.0.0.1) transmit(::1) receive(::1) transmit(127.0.0.1) receive(127.0.0.1) transmit(::1) receive(::1) transmit(127.0.0.1) receive(127.0.0.1) transmit(::1) receive(::1) transmit(127.0.0.1) receive(127.0.0.1) ::1: Server dropped: strata too high 127.0.0.1: Server dropped: strata too high server ::1, port 123 stratum 16, precision -20, leap 11, trust 000 refid [::1], delay 0.02573, dispersion 0.00000 transmitted 4, in filter 4 reference time: 00000000.00000000 Thu, Feb 7 2036 6:28:16.000 originate timestamp: ddbf0da9.473a860b Tue, Nov 21 2017 20:40:09.278 transmit timestamp: ddbf0da9.47320583 Tue, Nov 21 2017 20:40:09.278 filter delay: 0.02579 0.02573 0.02574 0.02573 0.00000 0.00000 0.00000 0.00000 filter offset: 0.000018 -0.00001 -0.00000 -0.00001 0.000000 0.000000 0.000000 0.000000 delay 0.02573, dispersion 0.00000 offset -0.000011 server 127.0.0.1, port 123 stratum 16, precision -20, leap 11, trust 000 refid [127.0.0.1], delay 0.02570, dispersion 0.00000 transmitted 4, in filter 4 reference time: 00000000.00000000 Thu, Feb 7 2036 6:28:16.000 originate timestamp: ddbf0da9.7a812105 Tue, Nov 21 2017 20:40:09.478 transmit timestamp: ddbf0da9.7a7990a1 Tue, Nov 21 2017 20:40:09.478 filter delay: 0.02571 0.02570 0.02570 0.02570 0.00000 0.00000 0.00000 0.00000 filter offset: -0.00000 -0.00001 -0.00001 -0.00001 0.000000 0.000000 0.000000 0.000000 delay 0.02570, dispersion 0.00000 offset -0.000013 21 Nov 20:40:09 ntpdate: no server suitable for synchronization found What am I doing wrong? Why ntp does not get time from system clock?

In a Clean Alpine Linux install run

apk add openntpd
service openntpd start
rc-update add openntpd

Then modifiy the /etc/ntpd.conf to

# $OpenBSD: ntpd.conf,v 1.16 2019/11/06 19:04:12 deraadt Exp $
#
# See ntpd.conf(5) and /etc/examples/ntpd.conf

servers pool.ntp.org
server time.cloudflare.com
sensor *

constraint from "9.9.9.9"              # quad9 v4 without DNS
constraint from "2620:fe::fe"          # quad9 v6 without DNS
constraints from "www.google.com"      # intentionally not 8.8.8.8

listen on 0.0.0.0

And run

service openntpd restart

Run a port scan against the server from another machine with nmap that shows that is not listening to NTP requests ergo not working. My logs when restarting the server, filtering the kernel logs, with older logs removed, also filtered the sshd login line

Feb  3 12:05:40 ns1 user.debug : Will stop /usr/sbin/ntpd
Feb  3 12:05:40 ns1 user.debug : Will stop PID 2480
Feb  3 12:05:40 ns1 user.debug : Sending signal 15 to PID 2480
Feb  3 12:05:59 ns1 daemon.info init: starting pid 2815, tty '': '/sbin/openrc shutdown'
Feb  3 12:05:59 ns1 user.debug : Will stop /usr/sbin/sshd
Feb  3 12:05:59 ns1 user.debug : Will stop PID 2526
Feb  3 12:05:59 ns1 user.debug : Sending signal 15 to PID 2526
Feb  3 12:05:59 ns1 auth.info sshd: Received signal 15; terminating.
Feb  3 12:05:59 ns1 auth.info sshd: Exiting on signal 15
Feb  3 12:05:59 ns1 user.debug : Will stop /usr/sbin/ntpd
Feb  3 12:05:59 ns1 user.debug : Will stop PID 2796
Feb  3 12:05:59 ns1 user.debug : Sending signal 15 to PID 2796
Feb  3 12:06:00 ns1 user.debug : Will stop PID 2451
Feb  3 12:06:00 ns1 user.debug : Sending signal 15 to PID 2451
Feb  3 12:06:00 ns1 user.debug : Will stop /usr/sbin/crond
Feb  3 12:06:00 ns1 user.debug : Will stop PID 2416
Feb  3 12:06:00 ns1 user.debug : Sending signal 15 to PID 2416
Feb  3 12:06:00 ns1 user.debug : Will stop /sbin/syslogd
Feb  3 12:06:00 ns1 user.debug : Will stop PID 2363
Feb  3 12:06:00 ns1 syslog.info syslogd exiting
Feb  3 12:06:18 ns1 syslog.info syslogd started: BusyBox v1.36.1
Feb  3 12:06:18 ns1 daemon.info init: starting pid 2343, tty '': '/sbin/openrc default'
Feb  3 12:06:18 ns1 cron.info crond: crond (busybox 1.36.1) started, log level 8
Feb  3 12:06:19 ns1 auth.info sshd: Server listening on 0.0.0.0 port 22.
Feb  3 12:06:19 ns1 auth.info sshd: Server listening on :: port 22.
Feb  3 12:06:19 ns1 daemon.info init: starting pid 2502, tty '/dev/tty1': '/sbin/getty 38400 tty1'
Feb  3 12:06:19 ns1 daemon.info init: starting pid 2503, tty '/dev/tty2': '/sbin/getty 38400 tty2'
Feb  3 12:06:19 ns1 daemon.info init: starting pid 2507, tty '/dev/tty3': '/sbin/getty 38400 tty3'
Feb  3 12:06:19 ns1 daemon.info init: starting pid 2511, tty '/dev/tty4': '/sbin/getty 38400 tty4'
Feb  3 12:06:19 ns1 daemon.info init: starting pid 2514, tty '/dev/tty5': '/sbin/getty 38400 tty5'
Feb  3 12:06:19 ns1 daemon.info init: starting pid 2518, tty '/dev/tty6': '/sbin/getty 38400 tty6'
Feb  3 12:06:19 ns1 daemon.info init: starting pid 2523, tty '/dev/ttyS0': '/sbin/getty -L 0 ttyS0 vt100'

Why no this configuration is making it a NTP server?

When configuring an NTP server with only the local clock, the server isn't usable to clients until over three minutes after ntpd starts by default. This is with "server 127.127.1.0 prefer". I've been able to reduce the delay to 15-20 seconds with the configuration "server 127.127.1.0 prefer true iburst minpoll 4". Is there a way to remove the delay or reduce it further? The version of ntpd I'm using is based on the one from ntp.org.

I am new to this business, and could not find the answers to the following: - In order for ntpd client to sync up with chronyd server using a hex key value, I found that I need to strip out the HEX: prefix from the hex keys used by chronyd before I upload this key file to my ntpd client. Is this is a known fact about this type of interworking, or a specific issue with my client? - ntpd requires full key length when using hex keys, i.e., SHA-1 has to be 40-hex symbols, SHA-256 64-hex symbols. Is this design intent of ntpd, and a known practice used by IT when generating and configuring ntpd keys? - ntpd implementation assumes (even in latest version ntp4.2.8p17) that if strlen(key) 20 characters, then it is treated as hex format. 1) Why 20 is the boundary limit to make this segregation? Gathering from RFCs, MD5 digest is 128 bits, SHA-1 digest is 160 bits, SHA256 is 256, etc. Was the 20-characters limit based on early implementation of ntpd when MD5 and SHA-1 were only on mind? 2) Is this 20-character limit known and expected by IT folks in industry, and accepted as a de-facto standard? 3) What repercussions can you think of if this limit is changed to be based on key type, i.e., if SHA-1 then limit is 20, if SHA-256 then limit is 32,... Could this cause backward compatibility issues?

The log of an Asus router with Padavan firmware (might be similar to OpenWrt) showed: Dec 4 16:06:20 NTP Client: Synchronizing time to 0.nl.pool.ntp.org. Oct 24 18:18:18 NTP Client: System time changed, offset: -1107989283.092767s Oct 24 18:18:33 pppd: System time change detected. Something is wrong with the NTP update, because the current date is December 4th, not October 24th. The graphical user interface has no option to update the system date/time using NTP. How to make NTP to force updating the date/time?