Utility timedatectl shows wrong timezone information

ricardas · May 5, 2020, 1:01pm

Timezone information is set from within a snap but is displayed as UTC by timedatectl. Here is what I try:

I connect timezone-control interface to my snap.

I set timezone from within the snap using timedatectl, e.g. timedatectl set-timezone Europe/Berlin

I check the outcome:

$ timedatectl
                      Local time: Tue 2020-05-05 14:53:16 CEST
                  Universal time: Tue 2020-05-05 12:53:16 UTC
                        RTC time: n/a
                       Time zone: Europe/Berlin (CEST, +0200)
       System clock synchronized: yes
systemd-timesyncd.service active: yes
                 RTC in local TZ: no

$ ls -l /etc/localtime
lrwxrwxrwx 1 root root 18 Apr 27 16:35 /etc/localtime -> writable/localtime

$ ls -l /etc/writable/localtime
lrwxrwxrwx 1 root root 33 May  5 14:53 /etc/writable/localtime -> /usr/share/zoneinfo/Europe/Berlin

$ date
Tue May  5 14:55:40 CEST 2020

$ journalctl | grep zone
May 05 14:41:47 iot-gw audit[1129]: AVC apparmor="ALLOWED" operation="open" profile="snap.osram-dispatcher.dispatcher//null-/usr/bin/sudo" name="/usr/share/zoneinfo/GB" pid=1129 comm="sudo" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
May 05 14:41:47 iot-gw audit[1137]: AVC apparmor="ALLOWED" operation="open" profile="snap.osram-dispatcher.dispatcher//null-/usr/bin/sudo//null-/bin/date" name="/usr/share/zoneinfo/GB" pid=1137 comm="date" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
May 05 14:44:14 iot-gw systemd-timedated[1671]: /etc/localtime should be a symbolic link to a time zone data file in /usr/share/zoneinfo/.
May 05 14:52:51 iot-gw dbus-daemon[867]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service' requested by ':1.11' (uid=1000 pid=2908 comm="/usr/bin/timedatectl.real set-timezone Europe/Berl" label="unconfined")
May 05 14:52:51 iot-gw systemd-timedated[2910]: /etc/localtime should be a symbolic link to a time zone data file in /usr/share/zoneinfo/.
May 05 14:53:04 iot-gw systemd-timedated[2910]: Changed time zone to 'Europe/Berlin'.
May 05 14:57:10 iot-gw systemd-timedated[3566]: /etc/localtime should be a symbolic link to a time zone data file in /usr/share/zoneinfo/.
May 05 14:58:34 iot-gw audit[3769]: AVC apparmor="ALLOWED" operation="open" profile="snap.dalipro-iot.dalipro-iot//null-/bin/journalctl" name="/usr/share/zoneinfo/Europe/Berlin" pid=3769 comm="journalctl" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
May 05 14:58:47 iot-gw audit[3802]: AVC apparmor="ALLOWED" operation="open" profile="snap.dalipro-iot.dalipro-iot//null-/bin/journalctl" name="/usr/share/zoneinfo/Europe/Berlin" pid=3802 comm="journalctl" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

But if I check again after just a minute or two, timedatectl displays the timezone as UTC:

$ timedatectl
                      Local time: Tue 2020-05-05 12:57:10 UTC
                  Universal time: Tue 2020-05-05 12:57:10 UTC
                        RTC time: n/a
                       Time zone: n/a (UTC, +0000)
       System clock synchronized: yes
systemd-timesyncd.service active: yes
                 RTC in local TZ: no

ogra · May 5, 2020, 1:29pm

this has had issues on and off in the past, an easy/reliable workaround is to ship a small shell script that you ship as a daemon in your snap to run on boot and force the timezone …

here are two examples (indeed you dont need to use geoip lookup but can just hardcode a timezone):

github.com

ogra1/dashkiosk-image-config/blob/master/set-timezone

#! /bin/sh

set -e

DBURL="http://www.geoplugin.net/csv.gp?ip="

# query geoip database on boot and set the timezone accordingly
timeout="0"
while ! wget -q -O- $DBURL >/dev/null 2>&1; do
    if [ "$timeout" -ge "3" ]; then
        echo "timed out, giving up waiting..."
        exit 0
    fi
    echo "can not reach $DBURL, sleeping for 30 sec"
    sleep 30
done

MYTZ="$(wget -q -O- $DBURL|grep geoplugin_timezone|sed 's/geoplugin_timezone,//')"

while ! timedatectl set-timezone "$MYTZ"; do

This file has been truncated. show original

and

ricardas · May 6, 2020, 8:23am

The version I am currently on is

$ snap version
snap    2.44.3
snapd   2.44.3
series  16
kernel  4.15.0-1061-raspi2

ricardas · May 6, 2020, 8:29am

Is it perhaps understood already and can be confirmed that this is just a “cosmetic” issue affecting timedatectl utility only?

Even though timedatectl won’t show the timezone, looks like I can deduce timezone information reliably from

$ ls -l /etc/writable/localtime
lrwxrwxrwx 1 root root 33 May  5 14:53 /etc/writable/localtime -> /usr/share/zoneinfo/Europe/Berlin

And if I query the date/time information via date utility, the returned value is adjusted to the set time zone and not UTC

$ date
Tue May  5 14:55:40 CEST 2020

ogra · May 6, 2020, 8:40am

yes, timedatectl has issues with the double-linking …

jamesh · May 6, 2020, 11:16am

That’s quite possible. The timedatectl command makes use of a D-Bus service that will be activated on first use, and then exit after a period of inactivity.

Based on the /etc/localtime should be a symbolic link to a time zone data file in /usr/share/zoneinfo/. error, the backend service probably can’t determine the current time zone at start up.

If you run timedatectl right after changing the time zone, it probably returns the time zone it has just set. If you wait a while, you’re probably talking to a new instance of the systemd-timedated which doesn’t know the time zone again.