3

I have a Dell SC1430 running XUbuntu 16.04 acting as a Mythtv backend server. It's been running fine for many years but now after upgrading from 12.04, via 14.04 to 16.04 (using do-release-upgrade) the system time is off by 2 hours and it can't be set to the correct time.

When I, or any mechanism such as ntpd or timesyncd, tries to set the time, it immediately changes back. I get this in syslog when trying ntpd:

Sep 17 12:32:33 eddie ntpd[21484]: proto: precision = 0.131 usec (-23)
Sep 17 12:32:33 eddie ntpd[21484]: restrict 0.0.0.0: KOD does nothing without LIMITED.
Sep 17 12:32:33 eddie ntpd[21484]: restrict ::: KOD does nothing without LIMITED.
Sep 17 12:32:33 eddie ntpd[21484]: Listen and drop on 0 v6wildcard [::]:123
Sep 17 12:32:33 eddie ntpd[21484]: Listen and drop on 1 v4wildcard 0.0.0.0:123
Sep 17 12:32:33 eddie ntpd[21484]: Listen normally on 2 lo 127.0.0.1:123
Sep 17 12:32:33 eddie ntpd[21484]: Listen normally on 3 eth0 192.168.1.11:123
Sep 17 12:32:33 eddie ntpd[21484]: Listen normally on 4 lo [::1]:123
Sep 17 12:32:33 eddie ntpd[21484]: Listen normally on 5 eth0 [fe80::219:b9ff:fe22:9d01%2]:123
Sep 17 12:32:33 eddie ntpd[21484]: Listening on routing socket on fd #22 for interface updates
Sep 17 10:32:52 eddie systemd[28438]: Time has been changed
Sep 17 10:32:52 eddie ntpd[21484]: ntpd: time set -7188.398130 s
Sep 17 10:32:52 eddie systemd[2506]: Time has been changed
Sep 17 10:32:52 eddie systemd[1]: Time has been changed
Sep 17 12:32:41 eddie systemd[28438]: Time has been changed
Sep 17 12:32:41 eddie systemd[2506]: Time has been changed
Sep 17 12:32:41 eddie systemd[1]: Time has been changed

As you can see, the time actually changes for a moment, then something is changing it back.

Timedatectl status gives me:

root@eddie:~# timedatectl status 
      Local time: Sun 2017-09-17 14:24:12 CEST
  Universal time: Sun 2017-09-17 12:24:12 UTC
        RTC time: Sun 2017-09-17 12:24:12
       Time zone: Europe/Stockholm (CEST, +0200)
 Network time on: no
NTP synchronized: no
 RTC in local TZ: no

UTC should be 10:24:12 and Local time should be 12:24:12 in this example.

My best guess is that some other program/process is (trying) to keep the time correct but gets confused with timezone or whatnot after the upgrade.

As I suggested above I have tried using NTP instead of the timedatectl approach, but the behavior is exactly the same.

This is not a dual-boot situation that I've read others having issues with.

Any help would be greatly appreciated!

  • Sep 17 10:32:52 eddie systemd[28438]: Time has been changed so check what systemd time service is doing ;) Probably: hwclock --systoh Set the time to something and then do THAT command yourself. See if that changes your clock to the wrong time – Rinzwind Sep 17 '17 at 11:42
  • I did timedatectl set-time "12:00" and then hwclock --systohc but nothing changes permanently. I get the same type of entries in syslog - time changes back immediately. How can I check what systemd time service is doing? – erik Sep 17 '17 at 12:07
  • Use timedatectl to assure that your time zone is set correctly, then use the set-local-rtc option to set the clock to local/rtc. – heynnema Sep 17 '17 at 13:31
1

I'm a bit unsure what the problem was but I solved it by:

  1. Assuring ntp service doesn't start at boot (chmodding -x to /usr/sbin/ntpd)
  2. Logging in via keyboard at the server as opposed to ssh from another client.
  3. Resetting timezone and turning on "network time" in GUI
  4. Rebooting
  5. Assuring ntp service is started at boot
  6. Rebooting again

A few comments: In syslog it seemed that some systemd service was resetting the time after I tried to set time correctly. The process id:s revealed that my login via ssh was responsible for one of those processes and lightdm for the other one. Therefore I logged in via keyboard at the server itself to have only one systemd time service running.

Also, systemctl status systemd-timesyncd.service reported:

● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
  Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
           └─disable-with-time-daemon.conf
   Active: inactive (dead)
Condition: start condition failed at Sun 2017-09-17 16:09:41 CEST; 4min 35s ago
           ConditionFileIsExecutable=!/usr/sbin/ntpd was not met

Hence the chmodding of /usr/sbin/ntpd

  • You solution is not so clear... Why don't you simply uninstall ntpd? Since timesyncd is working, there's no need to keep them all working. I used ntpdate and ntp for many years, now timedatectl is enough. Another thing you must check is BIOS clock must rather set to UTC, so clock with be properly synchronized. – Redbob Sep 17 '17 at 15:03
  • @Redbob thanks for your input. Other packages depends on ntp. Furthermore, this is not about choosing a method, ntp or timedatectl, for internet time, it's about being able to change the time regardless of method. I also tried having BIOS clock in both UTC and local time, but that didn't change the behavior of the immediate resetting. – erik Sep 17 '17 at 17:39
  • You're sure, Erik. I didn't realize that ntp is time-server, as timedatectl is time-client. I guess datetimectl isn't synchonized with ntp. Verify if datetimectl is synchronized to ntp by timedatectl set-ntp true or $ timedatectl set-ntp false if it doesn't works. – Redbob Sep 18 '17 at 3:32

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.