Server Fault Asked on November 16, 2021
I’ve configured systemd timesyncd to get it’s time from a NTP server:
/etc/systemd/timesyncd.conf > NTP=ca.pool.ntp.org
systemctl restart systemd-timesyncd.service
timedatectl set-ntp true
The status is the following:
$ timedatectl status
...
Network time on: yes
NTP synchronized: no
As the output implies, the time is not synced, yet. Can someone please help me out with the following questions?
Just as a side note for people struggling with this issue, sometimes the synchronization won't work anyway on containerized systems (e.g. OpenVZ) if the host machine doesn't give proper rights.
The systemd-timesyncd
service won't start on containerized systems ; the service file contains the following directive:
ConditionVirtualization=!container
Trying to comment that and restarting the service might work but unless the host machine has given the right to the containerized one, you might have such error in the systemctl status systemd-timesyncd
output:
Aug 11 16:01:40 your-machine systemd-timesyncd[4736]: Failed to call clock_adjtime(): Operation not permitted
Answered by robin850 on November 16, 2021
Without installing any more packages... Turn NTP off, manually set the time to be close enough, turn NTP back on:
$ timedatectl set-ntp false
Get the approximate LOCAL time from the wall clock, your phone, the Internet. It doesn't need to be perfect because we'll turn ntp back on in a moment...
$ sudo timedatectl set-time "2019-06-22 13:41:00"
$ sudo timedatectl set-ntp true
Wait a few minutes. If the response in timedatectl does not change then you have networking issues.
$ timedatectl
Local time: Sat 2019-06-22 13:49:53 AEST
Universal time: Sat 2019-06-22 03:49:53 UTC
RTC time: Sat 2019-06-22 03:49:54
Time zone: Australia/Sydney (AEST, +1000)
System clock synchronized: no
NTP service: active
RTC in local TZ: no
The "System clock synchronized: no" will turn to "yes" when it has adjusted enough to be considered 'in sync'. Something like:
$ timedatectl
Local time: Wed 2020-07-22 09:50:32 AEST
Universal time: Tue 2020-07-21 23:50:32 UTC
RTC time: Tue 2020-07-21 23:50:32
Time zone: Australia/Sydney (AEST, +1000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
and
$ timedatectl timesync-status
Server: 91.189.91.157 (ntp.ubuntu.com)
Poll interval: 1min 4s (min: 32s; max 34min 8s)
Leap: normal
Version: 4
Stratum: 2
Reference: 8CCBCC4D
Precision: 1us (-24)
Root distance: 64.781ms (max: 5s)
Offset: -88.040ms
Delay: 754.084ms
Jitter: 78.200ms
Packet count: 8
Frequency: -187.812ppm
Who are you asking for the time?
$ cat /etc/systemd/timesyncd.conf
[Time]
NTP=pool.ntp.org
I expect this common pool is best, but some distributions might have their own, or a regional one or you might just have something outdated; that's ok, just be sure it exists and serves ntp. If there is one close that you can reach, like a corporate time server which is inside the firewall, you can set it here, or set a fallback server. See the docs for more.
How is the synchronization progressing?
$ timedatectl timesync-status
Server: 13.210.208.89 (au.pool.ntp.org)
Poll interval: 8min 32s (min: 32s; max 34min 8s)
Packet count: 0
This sync is going badly: it started at 30 secs, but has blown out to waiting over 8 minutes between polls. The packet count
is an incoming count; ie: there have been zero responses. See above for an example of a healthy one. The poll interval adjusts automagically relative to how badly your clock drifts.
Are there any error messages?
Check the syslog for clues to what the problem might be.
$ journalctl --unit=systemd-timesyncd.service
Jun 22 14:13:09 meebox systemd-timesyncd[8333]: Timed out waiting for reply from 103.214.220.220:123 (au.pool.ntp.org).
In this example, the outgoing packets were not getting any reply because the ntp packets were being blocked by a corporate firewall.
Answered by John Mee on November 16, 2021
To use an actual NTP implementation, you need to install and configure one, chrony
or maybe ntpd
. Do so if you require any monitoring of time performance. I will assume chrony.
Add iburst
to your pool
or server
lines in your config to speed up the initial few packets. It still may take a couple minutes to stabilize, be patient.
While editing chrony.conf, review when steps are allowed. For example, makestep 1.0 3
means in the first 3 updates after chronyd is started, an offset greater than 1 second sets the clock immediately. Going back in time is bad for some applications, so large steps often are not allowed once a system is running.
On the command line, every variable can be queried.
chronyc tracking
will show the current offset. Have an idea of what your requirements are, one second accuracy can easily tolerate tens of milliseconds offset.
chronyc makestep
with no arguments will make the current adjustment immediately. Not necessary usually, there is a corresponding config file directive, and chrony will steadily discipline the clock by itself. makestep
on the CLI is for fixing NTP interactively when you don't want to restart chronyd.
timesyncd
is an SNTP client that can set the time, but not discipline it gradually and continuously, nor filter remote NTP server based on quality. (It also cannot talk to time hardware or PTP, only NTP protocol.) A little better than
repeated ntpdate
, by which I mean not very good clock. Personally, I replace it on most servers.
About the only way to set the time with timesyncd is manually: timedatectl set-time "2019-01-15 00:40:16"
. It does not have robust means to discipline and monitor the clock. Basic NTP stats via timedatectl timesync-status
are a relatively new thing, I don't think that option is available in Red Hat 7 or Ubuntu 18.04.
systemd defines "syncronized" to be if NTP was ever used to tell Linux to adjust the clock. Specifically, if kernel discipline call adjtimex() returned without error, and not the initial state. See the source code, systemd/src/basic/time-util.c.
Answered by John Mahowald on November 16, 2021
Get help from others!
Recent Answers
Recent Questions
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP