How to configure timezone and nameserver (on Ubuntu Core)

I have a couple of questions:
1. To change resolv.conf and have it persistent across reboots, i read a couple of solutions:

(i) add a file “nodnsupdate” at “/etc/dhcp/dhclient-enter-hooks.d” with content:


make this file executable +x

(ii) uncomment the entry dns-name-servers server1, server2; in file:

 eg. supersede domain-name-servers;

what’s the better way to do so?
2. I am trying to set timezone using timedatectl:

timedatectl set-timezone <timezone>

it gets changed for about 5 minutes and falls back to UTC. Not sure what is changing it back. I have stopped systemd-timesyncd as well as systemd-timedated.

Also, i noticed

timedatectl set-ntp false

does not kill/stop systemd-timesyncd daemon


So if i don’t want to use ntp servers for syncing time do i need to stop it manually?

if you are talking about a classic ubuntu server install with snap support, setting the timezone should be done via:

sudo dpkg-reconfigure tzdata

and network settings (including nameserver) are typically set in /etc/network/interfaces (or in a file in the /etc/network/interfaces.d/ subdir)

@ogra I am using Ubuntu core.

Output of uname:

>>uname -a
Linux CCW4C02 4.4.0-93-generic #116-Ubuntu SMP Fri Aug 11 21:17:51 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux 

I tried:

sudo dpkg-reconfigure tzdata

but tzdata is not installed, tried installing with:

>>snap install tzdata
error: cannot install "tzdata": snap not found

I guess snap set command might help, will dig into it more

Ah, sorry, you “snap on ubuntu” in the title and the choice of the “snap” section kind of made it sound like snap on classic …


sudo timedatectl set-timezone <timezone>

should work …
and it definitely does for me on all images:

ogra@nanopi-air:~$ sudo timedatectl set-timezone Europe/Berlin
ogra@nanopi-air:~$ date
Tue Sep 19 11:47:06 CEST 2017
ogra@nanopi-air:~$ sudo reboot
Connection to closed by remote host.
$ ssh
ogra@nanopi-air:~$ date
Tue Sep 19 11:48:30 CEST 2017

What image (stable, edge ?) on what device are you using ?

Is this a self-created image or one of our reference ones and did you also use a proper timezone when calling the command … (“timedatectl list-timezones” lists all valid options)

1 Like

@ogra yes I am using valid timezone (Asia/Hong_Kong, listed in “timedatectl list-timezones”).

Also, it’s Dell 3001 on which i am using self created image.

one more thing

timedatectl set-ntp false

should stop “systemd-timesyncd” daemon right?

i wouldnt rely on that, after all there are certain systemd tools that were normally not used in xenial but are enabled on Ubuntu Core (networkd and timesyncd specifically, the safest option here is surely to disable systemd-timesyncd with systemctl instead.

@ogra thanks for the suggestion on using systemctl directly. Anything on timezone issue ?

for interface configuration (including nameservers) i’ll proceed with adding appropriate files in /etc/network/interfaces.d/

Ubuntu Core uses netplan, /etc/network/interfaces.d/ is not read by anything …

you either want to call

sudo console-conf

to change the config or manually edit /etc/netplan/00-snapd-config.yaml instead and call

sudo netplan generate
sudo netplan apply

some details are at:

I can observe the behavior that @Anmol mentioned: Setting the timezone to Europe/Berlin with timedatectl works fine, but gets reset after ~ 5 minutes. Running Ubuntu Core stable on a Raspberry Pi 3B.

snap info core

name:      core
summary:   snapd runtime environment
publisher: Canonical✓
license:   unset
description: |
  The core runtime environment for snapd
type:         core
snap-id:      99T7MUlRhtI3U0QFgl5mXXESAiSwt776
tracking:     stable
refresh-date: 6 days ago, at 15:06 CET
  stable:    16-2.36.1                 (5898) 78MB -    <

snap --version

snap    2.36.1
snapd   2.36.1
series  16
kernel  4.4.0-1100-raspi2

This sounds like, and I’ve a feeling we never really fixed it for good.

Just to point out, a nameserver is set correctly in systemd-resolved according to what DHCP hands out, so if you are in control of that then it works fine.

You can check it with resolvectl or cat /run/systemd/resolve/resolv.conf

Not saying that is relevant this particular scenario, but just in case someone else reads this and wonders.

Cheers, Just