Bug 1660846
| Summary: | timedatectl shows NTP synchronized: no, while with ntpstat the server is synchronized | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Markus Schibli <mschibli> |
| Component: | ntp | Assignee: | Miroslav Lichvar <mlichvar> |
| Status: | CLOSED WONTFIX | QA Contact: | qe-baseos-daemons |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.6 | CC: | dtardon, jss, systemd-maint-list, thozza, ysoni |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-06-27 11:47:46 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
The value for "NTP synchronized" is obtained by calling adjtimex() and then checking if the .status field of struct timex contains STA_UNSYNC. I assume it's ntpd that sets/unsets that flag... The -x option of ntpd disables the kernel discipline. The kernel doesn't know the system clock is synchronized by ntpd, and cannot report a synchronized status. timedatectl doesn't know anything about ntpd/chronyd and just looks at the kernel status. This may be unexpected, but it is working as designed. One possible solution would be to patch ntpd to use the ntp_adjtime() system function to just set the clock status and not control the clock when the -x option is enabled and ntpd uses adjtime() for controlling the clock. Here is a more detailed explanation of how it works: The kernel maintains an "unsynchronized" flag for the system clock. The timedatectl program from systemd will print "NTP synchronized: yes" only if this flag is cleared (set to zero). It doesn't support the protocol which ntpq and ntpstat use to query the state of ntpd. ntpd can control the system clock using two different system functions: - ntp_adjtime() enables a phase-locked loop implemented in the kernel (aka kernel discipline), which automatically corrects the frequency offset of the clock (drift) and it needs to be called only when a new measurement is made. It clears the "unsynchronized" flag in the kernel. The main limitation is that it cannot correct offsets larger than 0.5 seconds. - adjtime() is an older method, which makes a one-time adjustment of the clock (slew). It doesn't correct the frequency offset, so it needs to be called frequently to compensate for it, even when no measurement is made. It cannot clear the "unsynchronized" flag in the kernel, but it can correct any offset. ntpd can use ntp_adjtime() or adjtime(), but not both at the same time. By default it uses ntp_adjtime(). If the step threshold is set to a larger value than 0.5 seconds (e.g. by enabling the -x option), it has to switch to adjtime(), because ntp_adjtime() does not work with larger offsets. That means the kernel "unsynchronized" status will not be cleared and timedatectl will report "NTP synchronized: no" when ntpd is started with the -x option. Development Management has reviewed and declined this request. You may appeal this decision by reopening this request. *** Bug 1726671 has been marked as a duplicate of this bug. *** *** Bug 1726671 has been marked as a duplicate of this bug. *** *** Bug 1785488 has been marked as a duplicate of this bug. *** |
Description of problem: Customer is running their environment the ntpd in "slew" mode (ntpd -x). With running ntpd in "slew" mode, timedatectl does always show "NTP synchronized: no" while ntpstat correctly show "synchronised to NTP server (10.11.160.238) at stratum 2 " Version-Release number of selected component (if applicable): RHEL7.6 systemd-219-62.el7.x86_64 How reproducible: remove chrony package, install ntp package, configure ntpd to run in "slew" mode, wait some time to be synchronized, test timedatectl vs. ntpstat Steps to Reproduce: 1. yum remove chrony 2. yum install ntp 3. vi /etc/sysconfig/ntpd and add -x at the end of the OPTIONS line -> OPTIONS="-g -x" 4. systemctl enable ntpd.service 5. systemctl start ntpd.service / or / timedatectl set-ntp 1 6. *wait some time to be synchronized* 7. ntpstat 8. timedatectl | grep NTP Actual results: # timedatectl | grep NTP NTP enabled: yes NTP synchronized: no # ntpstat synchronised to NTP server (10.11.160.238) at stratum 2 time correct to within 10 ms polling server every 64 s # ps -wauxxx | grep ntp ntp 4343 0.0 0.0 29944 2140 ? Ss 11:33 0:00 /usr/sbin/ntpd -u ntp:ntp -g -x Expected results: # timedatectl | grep NTP NTP enabled: yes NTP synchronized: yes Additional info: I reproduced the problem on RHEL7.6/7.5/7.3 Customer won't use chrony in the near future. additional side note, there is another issue with ntpd running in "slew" mode, ntptime returns code 5 (ERROR) which is described in https://access.redhat.com/solutions/38542, which was leading me to the source of this timedatectl issue.