Time and date refuses to sync in HiFiBerryOS

Diederik

December 30, 2020 13:15

None

Edit changed title from How is time and date set in HiFiBerryOS to Time and date refuses to sync in HiFiBerryOS

Hi all,

I had an issue with Spotify Connect (which is now solved) and noticed there that after a fresh installation my date and time was completely off. Running the timedatectl command gave:

timedatectl
               Local time: Sat 2020-09-12 12:55:53 UTC
           Universal time: Sat 2020-09-12 12:55:53 UTC
                 RTC time: n/a
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no

It thought it was Sep 12 2020 but it was Dec 30 2020. The hour was off as well, even after changing the time zone with

timedatectl set-timezone 'Europe/Brussels'

So I was wondering, how does the HiFiBerry set its time and date during the installation? Or how should it do it?

Date Votes

4 comments

0

HiFiBerry team December 30, 2020 16:43

It's set by ntpd. According to your logs, ntp is running. I wonder why it didn't sync.
Can you try rebooting and then run

ntptime

This might give an idea why it didn't sync.

Comment actions Permalink
0

Diederik December 30, 2020 18:38

Thanks for the info that it is set by ntpd.

I will check if I have an unconfigured HiFiBerry that I can use to start from scratch.
I checked it some more and found that ntpd mentions not being able to sync when the difference is over 1000s https://linux.die.net/man/8/ntpd :
"In case there is no TOY chip or for some reason its time is more than 1000s from the server time, ntpd assumes something must be terribly wrong and the only reliable action is for the operator to intervene and set the clock by hand. "

So perhaps that was why it didn't work without me intervening manually first?

Comment actions Permalink

Diederik December 31, 2020 08:06

Hi HiFiBerry team,

I started my Raspberry Pi this morning. It was cut from the power last night around 19:00 and it seems ntpd can't sync again. I can change it manually. But because the Raspberry Pi is always shutdown when I leave my office I would like a more permanent solution.

So timedatectl gave

# timedatectl
               Local time: Wed 2020-12-30 19:20:38 CET
           Universal time: Wed 2020-12-30 18:20:38 UTC
                 RTC time: n/a
                Time zone: Europe/Brussels (CET, +0100)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no

And ntptime

# ntptime
ntp_gettime() returns code 0 (OK)
  time e3974402.4117b000  Wed, Dec 30 2020 19:22:58.254, (.254268),
  maximum error 16000000 us, estimated error 16000000 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 0.000 us, frequency 0.000 ppm, interval 1 s,
  maximum error 16000000 us, estimated error 16000000 us,
  status 0x41 (PLL,UNSYNC),
  time constant 7, precision 1.000 us, tolerance 500 ppm,

Additional info:

systemctl status ntpd.service

#systemctl status ntpd.serviceDescription=Network Time Service
LoadState=loaded
ActiveState=active
● ntpd.service - Network Time Service
     Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2020-12-30 19:05:58 CET; 1h 2min ago
    Process: 333 ExecStart=/usr/sbin/ntpd -g -p /run/ntpd.pid (code=exited, status=0/SUCCESS)
   Main PID: 355 (ntpd)
      Tasks: 1 (limit: 1544)
     CGroup: /system.slice/ntpd.service
             └─355 /usr/sbin/ntpd -g -p /run/ntpd.pid

Warning: journal has been rotated since unit was started, output may be incomplete.

cat /usr/lib/systemd/system/ntpd.service

# cat /usr/lib/systemd/system/ntpd.service
[Unit]
Description=Network Time Service
After=network.target

[Service]
Type=forking
PIDFile=/run/ntpd.pid
ExecStart=/usr/sbin/ntpd -g -p /run/ntpd.pid

[Install]
WantedBy=multi-user.target

cat /etc/ntp.conf

# cat /etc/ntp.conf
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server 2.pool.ntp.org iburst
server 3.pool.ntp.org iburst

# Allow only time queries, at a limited rate, sending KoD when in excess.
# Allow all local queries (IPv4, IPv6)
restrict default nomodify nopeer noquery limited kod
restrict 127.0.0.1
restrict [::1]

journalctl showed this

Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question time1.google.com IN DS: signature-expired
Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question time1.google.com IN SOA: signature-expired
Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question time1.google.com IN AAAA: signature-expired
Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question time1.google.com IN A: signature-expired
Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question com IN DS: signature-expired
Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question com IN DNSKEY: signature-expired
Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question google.com IN DS: signature-expired
Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question google.com IN SOA: signature-expired
Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question time2.google.com IN DS: signature-expired
Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question time2.google.com IN SOA: signature-expired
Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question time2.google.com IN A: signature-expired
Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question time2.google.com IN AAAA: signature-expired
Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question com IN DS: signature-expired
Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question com IN DNSKEY: signature-expired
Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question google.com IN DS: signature-expired
Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question google.com IN SOA: signature-expired
Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question time3.google.com IN DS: signature-expired
Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question time3.google.com IN SOA: signature-expired
Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question time3.google.com IN AAAA: signature-expired
Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question time3.google.com IN A: signature-expired
Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question com IN DS: signature-expired
Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question com IN DNSKEY: signature-expired
Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question google.com IN DS: signature-expired
Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question time4.google.com IN DS: signature-expired
Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question time4.google.com IN SOA: signature-expired
Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question time4.google.com IN A: signature-expired
Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question time4.google.com IN AAAA: signature-expired
Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question com IN DS: signature-expired
Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question com IN DNSKEY: signature-expired
Dec 30 20:21:38 hifiberry2 systemd-resolved[180]: DNSSEC validation failed for question google.com IN DS: signature-expired

I noticed the -g flag in the /usr/lib/systemd/system/ntpd.service so I thought this would have done the force sync?

Then I noticed the journalctl which seems to mention logs trying to obtain time? Seems like a vicious circle: can't get time because my signature in requests are expired and can't not-expired requests because my time is completely off...

Been struggling with this for a while now... I'll update it manually for now and pick this up later. Seems like a bug to me if this is the default configuration?

EDIT: I found this https://github.com/systemd/systemd/issues/5873#issuecomment-650659432, which I will try for now...

Edited by Diederik January 08, 2021 16:59

Mikey McLellan May 16, 2021 03:20

Looks like the currently accepted systemd workaround is this.

Basically turn off DNSSEC when setting time (?)

I'm trialing it now

### /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service

# Turn off DNSSEC validation for hostname look-ups, since those need the
# correct time to work, but we likely won't acquire that without NTP. Let's
# break this chicken-and-egg cycle here.
Environment=SYSTEMD_NSS_RESOLVE_VALIDATE=0

Please sign in to leave a comment.