Chrony and NTP - Raspberry Pi Configuration Weirdness

lstocky · October 16, 2019, 11:42am

Hi Balena crowd

I’m seeing some weird behaviour on my Raspberry Pi 3 with screenly installed (running on balena). But never mind screenly, if I go to the Host OS and run timedatectl I get this:

Local time: Wed 2019-10-16 11:29:48 UTC
           Universal time: Wed 2019-10-16 11:29:48 UTC
                 RTC time: n/a
                Time zone: n/a (UTC, +0000)
System clock synchronized: yes
              NTP service: n/a
          RTC in local TZ: no

I want for chrony to be configuring my pi with the local time zone Europe/London.
To me, the above output from timedatectl suggests that chrony isn’t working/configured properly.

Question 1 - am I right?

FYI - if I run the dbus command specified here then I get this:

method return time=1571225515.654175 sender=:1.51197 -> destination=:1.51196 serial=4 reply_serial=2
   array [
      dict entry(
         string "Timezone"
         variant             string ""
      )
      dict entry(
         string "LocalRTC"
         variant             boolean false
      )
      dict entry(
         string "CanNTP"
         variant             boolean false
      )
      dict entry(
         string "NTP"
         variant             boolean false
      )
      dict entry(
         string "NTPSynchronized"
         variant             boolean true
      )
      dict entry(
         string "TimeUSec"
         variant             uint64 1571225515653548
      )
      dict entry(
         string "RTCTimeUSec"
         variant             uint64 0
      )
   ]

Question 2 - what does this tell me about the problem with chrony?

Finally, if I run this systemctl status chronyd, it returns as follows:
● chronyd.service - NTP client/server
Loaded: loaded (/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/chronyd.service.d
└─chronyd.conf
Active: active (running) since Tue 2019-09-17 13:00:58 UTC; 4 weeks 0 days ago
Docs: man:chronyd(8)
man:chrony.conf(5)
Main PID: 695 (chronyd)
Tasks: 1 (limit: 1910)
Memory: 1.1M
CGroup: /system.slice/chronyd.service
└─695 /usr/sbin/chronyd -s -d

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

Once again, I’m really none the wiser

Question 3: How do I get my device configured using the Europe/London timezone? Bear in mind that I have consulted the time management pages. The answer still evades me - needless to say, I am new to all this.

Really appreciate any guidance to help fix the problem with chrony and get the hostos (balenaOS 2.43.0+rev1) properly configured with the correct timezone.

Thanks

xginn8 · October 16, 2019, 5:10pm

Hi there,

I will do my best to answer your questions one by one:

That output indicates that the system clock is being disciplined appropriately: System clock synchronized: yes.
From the look of it, there is not an issue with your chrony instance. You can get more detailed sync information from chrony via chronyc sources.
Why do you need to alter the host OS timezone? It should be trivial to set a custom timezone from within a container (there are many ways to do this, including env vars). The timezone is only cosmetic, NTP syncs to coordinated universal time and then an offset is applied based on that timezone. For example, to set that timezone in your Dockerfile, you can define the variable ENV TZ=Europe/London to set the appropriate timezone within the container.

I hope this helps shed some light on time synchronization!

lstocky · October 18, 2019, 7:49pm

Hi @xginn8

Thanks for your helpful responses.

ok good
chrony sources returns

210 Number of sources = 4
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^- time.videxio.net 2 10 377 132 +622us[ +622us] +/- 69ms
^+ 183.ip-51-89-151.eu 3 10 377 609 +646us[ +646us] +/- 15ms
^+ ntp2.wirehive.net 2 10 377 51 +396us[ +396us] +/- 18ms
^* ns0.thorcom.net 1 10 377 693 -88us[ +92us] +/- 13ms

I assumed that if the host OS time is off that all related services/containers would be off as well as they would be relying on the hostOS for reference. Your comments seem to imply that I should not be concerned about the correct timezone in the hostOS.
As I’m running screenly on top of balena, at that point the timezone is more than cosmetic (as you appreciate). I need signs to display at the correct time based on the specified schedule.

I have defined the variable you mention, though the use of ENV appears to be what is specified in the docker file (according to this). So instead, I created a new Environment Variable called TIMEZONE with value Europe/London.
Doing so hasn’t made any difference to the results of running timedatectl ;-/ should it?

So I’m still left with my original puzzle - and perhaps this is where I will have to go back to the screenly forums - how do I check that screenly is configured against the correct timezone…?

Thank you again.

xginn8 · October 21, 2019, 3:26pm

Hi again @lstocky,

That chronyc output looks good & correct (time is being properly disciplined).

timedatectl in the host OS will not be affected by any changes you make to environment variables, however your container should reflect the change. I believe you need to set the TZ environment variable rather than TIMEZONE for Debian-based containers (I have confirmed this on both Stretch and Buster). That sample project uses TIMEZONE to write to the /etc/timezone file (https://github.com/balena-io-playground/balena-timezone/blob/master/start.sh#L6), so it’s not directly related to what you are seeing.

If you can set TZ for your container I believe it should fix the issue!

lstocky · October 21, 2019, 4:46pm

Hi @xginn8

Thanks for the update - just to clarify - I see that you’re saying I should use TZ instead of TIMEZONE. You wrote that I should set TZ for ‘your container’. Does that mean the configuration from the ‘Device Environment Variables’ page is not possible or can I set the environment variable from there too?

As a matter of fact, I tried changing the environment variable TIMEZONE to TZ and that has no impact on the result of running timedatectl on the HostOS. It continues to return Time zone: n/a (UTC, +0000)

Thank you!

xginn8 · October 21, 2019, 5:36pm

Hi again,

There are a few ways to set the environment variables (per-device, per-fleet, via the balenaCloud UI or Dockerfile/docker-compose directly). You can read more about how exactly to manipulate those variables here: https://www.balena.io/docs/learn/manage/serv-vars/.

As I mentioned above, these environment variables only affect the service containers running on the device, and do not modify anything in the host OS. You should try running something like date inside your container to confirm the timezone has been properly applied:

root@514335b:/usr/src/app# date
Mon Oct 21 18:33:57 BST 2019

lstocky · October 21, 2019, 5:58pm

@xginn8

It worked - so as you explained, the environment variables (configured through the balena UI) affect the service containers not the hostOS. I ran date inside srcreenly-server and it correctly returns:
Mon Oct 21 18:56:15 BST 2019

Thanks for your help, all good.

lstocky · October 21, 2019, 6:44pm

I might just recommend that the documentation here:

be updated to clarify that the variable to be declared is TZ, not TIMEZONE. At least in my case, that was what made the difference.