Ubuntu Core timedatectl setting incorrect time, config missing servers, cannot be modified and reverts to UCT after a few minutes

Question

Ubuntu core instance starts up with date: Sun Aug 21 01:31:59 2016 (and after trying to correct settings with NTP disabled and reboot, date is: Wed Nov 2 16:59:29 (LocalTime) 2016), whereas the actual time was Sun Oct 15 10:01:01 (LocalTime) 2017.

This seems to be caused by timedatectl trying to set the network time without any servers configured. sudo cat /etc/systemd/timesyncd.conf gives:

[Time]  
#NTP=   
#FallbackNTP=ntp.ubuntu.com

Due to the nature of the core snap, this config file cannot be corrected.

Changing the date or time, with timedatectl's NTP still active reverts to the incorrect time. After set-ntp false it is possible to correct the date and time, lasting until the next reboot, due to lack of a hardware clock on my test unit.

Setting the time zone to my time zone works correctly, for a few minutes. Initially timedatectl status displays the correct timezone after Local Time, but then reverts to UTC. Output from date command indicates the local zone so the settings is successful in other areas, only timedatectl reports the wrong timezone.

Is this a bug, or am I missing the method to configure this correctly?

EDIT: Not being able to edit /etc/systemd/timesyncd.conf was an issue with pinano, using vi I was able to edit the file, will monitor it, but the config should also include a default NTP server, I believe.

---

Output from snap list:

avahi       0.6.32        44    ondra      - 
core        16-2.28.1     3025  canonical  core 
nextcloud   11.0.4snap1   2713  nextcloud  - 
pi2-kernel  4.4.0-1030-3  22    canonical  kernel 
pi3         16.04-0.5     6     canonical  gadget 
pinano      2.8.7         8     vbota      -   

Answer 1

I am marking this as answered, seeing as the main issue - the incorrect time from NTP - can be solved by editing with vi.

I am leaving this up here for anyone else experiencing the same issue, since I could not find a reference to the issue anywhere else when I did a search. Also, as I believe there are some minor defects in the tools used, resulting in the problem occurring, and this serves as a note of that.

Answer 2

The timezone reverting in timedatectl output seems to be a bug.

The journal has this:

systemd-timedated[5870]: /etc/localtime should be a symbolic link to a time zone data file in /usr/share/zoneinfo/.

The file is an indirect link:

# ls -lah /etc/localtime /etc/writable/localtime
lrwxrwxrwx 1 root root 23 Jul 27 20:07 /etc/localtime -> /etc/writable/localtime
lrwxrwxrwx 1 root root 39 Aug 27 10:08 /etc/writable/localtime -> /usr/share/zoneinfo/TZContinent/TZCity

The date command reports the correct time.