1

I have a server (Ubuntu 20.04) with an asynchronous time (wrong by around 7.5 minutes; RTC already seems to be equal/close to the "real" time) which I want to correct:

timedatectl
               Local time: Do 2021-04-08 14:32:02 CEST
           Universal time: Do 2021-04-08 12:32:02 UTC
                 RTC time: Do 2021-04-08 12:24:16
                Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: no
              NTP service: n/a
          RTC in local TZ: no

To do so I have included some time servers in my /etc/ntp.conf (as described here) and restarted ntp via sudo service ntp restart:

server 0.de.pool.ntp.org
server 1.de.pool.ntp.org
server 2.de.pool.ntp.org
server 3.de.pool.ntp.org

Then I did sudo timedatectl set-time 14:25:00 to set the system clock to the specified time so that the unsynchronized system time will be rather close to the "real" time.

Afterwards the time actually seems to be (more) correct (although saying "System clock synchronized: no"):

timedatectl
               Local time: Do 2021-04-08 14:25:04 CEST
           Universal time: Do 2021-04-08 12:25:04 UTC
                 RTC time: Do 2021-04-08 12:25:04
                Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: no
              NTP service: n/a
          RTC in local TZ: no

But suddenly (about half a minute later) I get this again (Local/Universal time != RTC time):

timedatectl
               Local time: Do 2021-04-08 14:33:15 CEST
           Universal time: Do 2021-04-08 12:33:15 UTC
                 RTC time: Do 2021-04-08 12:25:29
                Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: no
              NTP service: n/a
          RTC in local TZ: no

What kind of mechanism may interfere here which resets the "Local time" to the wrong time every time again?

[Update]

Ok, by now I have understood that there are actually two separate ways to manage/sync the time in Ubuntu:

Old way:

ntp (more exactly ntpd with its config file /etc/ntp.conf) -> which is probably still installed on my system as it has been upgraded several times from older Ubuntu distributions

New way:

timesyncd which seems to be the new way since Ubuntu 16.04 (with config file /etc/systemd/timesyncd.conf):

[...] That shall ensure that no two time syncing services are fighting. While no more recommended to be used, this still also applies to ntpd being installed to retain any kind of old behavior/config that you had through an upgrade. But it also implies that on an upgrade from a former release ntp/ntpdate might still be installed and therefore renders the new systemd based services disabled.

ntpdate is considered deprecated in favor of timedatectl (or chrony) and thereby no more installed by default. timesyncd will generally do the right thing keeping your time in sync [...]

Attention: ntp/ntpd != NTP protocol

The old ntpd service which I suppose is installed via sudo apt-get install ntp is not the same as the NTP protocol itself. This caused a lot of confusion when reading articles about this issue because in the context of timesyncd the NTP protocol is of course used but this has nothing to do with the ntp installation/ntpd command as I understand it.

13
  • 1
    When using timedatectl you should be setting your NTP servers in /etc/systemd/timesyncd.conf not in /etc/ntp.conf since that file is used directly by the ntp command. Servers are separated by spaces in the /etc/systemd/timesyncd.conf file.
    – Terrance
    Apr 8 at 13:42
  • 1
    I'm not sure what it defaults to when the file doesn't exist. However, the file is normally commented out anyway so you could create one and then set your servers in it. Arch Linux has a good example there: wiki.archlinux.org/index.php/systemd-timesyncd With systemd the timedatectl is the preferred way.
    – Terrance
    Apr 8 at 13:58
  • 1
    However, if you want to use ntp it still can be installed into 20.04. askubuntu.com/a/1046217/231142
    – Terrance
    Apr 8 at 14:01
  • 1
    Installing timesyncd again should remove ntp. Run the command sudo apt install systemd-timesyncd. Then refer to some of these answers to configure timesyncd. Apr 9 at 11:47
  • 1
    Glad it worked either way. :-) For your Q&A to follow the standards of this site, you should extract your answer from your original question (including the steps you took to make it work), and post it as your own answer that you accept. In that way, the question and the solution are clear and separate for future reference. Apr 9 at 12:42
2

I still don't know why that original issue (time reset back to wrong time) has actually happened but I could get my time finally working by uninstalling ntp (sudo apt-get remove ntp) which automatically installed and configured systemd-timesyncd instead so that all my system times finally set themselves to the correct setting:

Still asynchronous after installation:

$ timedatectl
               Local time: Fr 2021-04-09 14:04:45 CEST
           Universal time: Fr 2021-04-09 12:04:45 UTC
                 RTC time: Fr 2021-04-09 12:12:31
                Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Some minutes later everything is finally fine:

$ timedatectl
               Local time: Fr 2021-04-09 14:08:54 CEST
           Universal time: Fr 2021-04-09 12:08:54 UTC
                 RTC time: Fr 2021-04-09 12:08:54
                Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Thanks a lot for your help!

0

RTC is the real-time-clock, the BIOS-battery powered hardware time. Your BIOS-battery might be failing and as a result the drift of the hardware clock is worse then it should be.

1
  • The problem was not that the time drifted more and more but that it suddenly set itself back to the 7.5 minute offset after about one minute after it was set manually to the correct time. Apr 9 at 12:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.