Description of problem: When using systemd-timesyncd, timedatectl still claims that the clock is synchronized via NTP after switching NTP off. Version-Release number of selected component (if applicable): systemd-219-24.fc22.x86_64 How reproducible: Always Steps to Reproduce: 1. systemctl disable timedatex 2. systemctl stop timedatex 3. timedatectl set-ntp on 4. Wait until you see "NTP synchronized: yes" 5. timedatectl set-ntp off Actual results: timedatectl keeps showing "NTP synchronized: yes". Expected results: "NTP synchronized: no". Additional info: The same happens when breaking the timesyncd configuration, maybe like this # echo NTP=foo.bar.blargl >/etc/systemd/timesyncd.conf.d/50-broken.conf # systemctl restart systemd-timesyncd The clock is not really synchronized anymore, but timedatectl pretends that it is. Setting the time manually via 'timedatectl' or 'date' resets the state to "NTP synchronized: no".
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This still happens in current Fedora 34 with systemd-248-2.fc34.x86_64.
NTP synchronized: yes/no is reflecting the status of check done with adjtimex(2): when adjtimex reports some "maxerror" that is not the maximum, this is understood to mean that the clock is (or possibly was recently) synchronized. See https://github.com/systemd/systemd/commit/bca5a0eacc. So it is expected to see "synchronized:yes" for some time after disabling an ntp service. This seems correct to me, since simply disabling the service does not invalidate the clock immediately.
Ah, thanks Zbigniew for the explanation!