[PROBLEM] Wrong date/time

[Sehnsucht]

I just noticed both my moOde boxes have the wrong date/time.  Pretty sure it's been correct for years.

I'm on version...well, not sure where the version is but my install log ends with:

20230317 090950 updater: Finish 2023-03-14 update for moOde

Isn't incorrect date/time a potential cause of authentication issues?

[Tim Curtis]

I've never seen that message before.

After rebooting do the following:

Menu, Configure, System
Menu, System info

The current time is printed in the System Parameters block near the top.

[Sehnsucht]

I've never seen that message before.

Sorry, that last line was in the wrong font - not part of the log!

Ah - never realised the menu gave different options from different pages!

moOde release = 8.3.0 2023-03-14
RaspiOS = 11.6
Linux kernel = 5.15.84-v8+ #1613
Platform = Pi-4B 1.1 2GB
Architecture = aarch64 (64-bit)
System uptime = up 3 hours, 57 minutes
Timezone = Europe/London
Current time = 2023-06-06 22:24:03

Yeah, that's not the right date/time.

The other one:

moOde release = 8.3.0 2023-03-14
RaspiOS = 11.2
Linux kernel = 5.15.84+ #1613
Platform = Pi-Zero W 1.1 512MB
Architecture = armhf (32-bit)
System uptime = up 1 minute
Timezone = Europe/London
Current time = 2023-06-05 22:36:34

Very similar date/time.

[Tim Curtis]

Check the time sync service from command line. If it is not able to connect to Internet time servers there should be some errors.

Command

Code:

systemctl status systemd-timesyncd

Example

Code:

pi@moode:~ $ systemctl status systemd-timesyncd
● systemd-timesyncd.service - Network Time Synchronization
    Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
    Active: active (running) since Mon 2023-06-12 21:52:08 EDT; 10h ago
      Docs: man:systemd-timesyncd.service(8)
  Main PID: 336 (systemd-timesyn)
    Status: "Initial synchronization to time server 173.11.101.155:123 (2.debian.pool.ntp.org)."
     Tasks: 2 (limit: 1009)
       CPU: 744ms
    CGroup: /system.slice/systemd-timesyncd.service
            └─336 /lib/systemd/systemd-timesyncd

Jun 12 09:41:57 moode systemd[1]: Starting Network Time Synchronization...
Jun 12 09:41:57 moode systemd-timesyncd[336]: System clock time unset or jumped backwards, restoring from recorded timestamp: Mon 2023-06-12 21:52:08 EDT
Jun 12 21:52:08 moode systemd[1]: Started Network Time Synchronization.
Jun 13 06:46:46 moode systemd-timesyncd[336]: Initial synchronization to time server 173.11.101.155:123 (2.debian.pool.ntp.org).

[Sehnsucht]

Check the time sync service from command line. If it is not able to connect to Internet time servers there should be some errors.

Command

Code:

systemctl status systemd-timesyncd

Here's what I get plus proof the internet is fine:

Code:

pi@electro:~ $ systemctl status systemd-timesyncd
● systemd-timesyncd.service - Network Time Synchronization
    Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
    Active: active (running) since Tue 2023-06-06 18:22:54 BST; 30s ago
      Docs: man:systemd-timesyncd.service(8)
  Main PID: 1039 (systemd-timesyn)
    Status: "Idle."
     Tasks: 2 (limit: 2137)
       CPU: 120ms
    CGroup: /system.slice/systemd-timesyncd.service
            └─1039 /lib/systemd/systemd-timesyncd

Jun 06 18:22:54 electro systemd[1]: Starting Network Time Synchronization...
Jun 06 18:22:54 electro systemd[1]: Started Network Time Synchronization.
Jun 06 18:23:04 electro systemd-timesyncd[1039]: Timed out waiting for reply from 192.168.4.1:123 (192.168.4.1).

pi@electro:~ $ date
Tue 06 Jun 2023 06:23:35 PM BST

pi@electro:~ $ wget www.bbc.co.uk
--2023-06-06 18:26:29--  http://www.bbc.co.uk/
Resolving www.bbc.co.uk (www.bbc.co.uk)... 212.58.235.1, 212.58.237.129, 212.58.236.1, ...
Connecting to www.bbc.co.uk (www.bbc.co.uk)|212.58.235.1|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://www.bbc.co.uk/ [following]
--2023-06-06 18:26:29--  https://www.bbc.co.uk/
Connecting to www.bbc.co.uk (www.bbc.co.uk)|212.58.235.1|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 604140 (590K) [text/html]
Saving to: ‘index.html’

index.html                                            100%[=======================================================================================================================>] 589.98K  --.-KB/s    in 0.09s    

2023-06-06 18:26:30 (6.73 MB/s) - ‘index.html’ saved [604140/604140]

[TheOldPresbyope]

@Sehnsucht 

This seems like a red flag:

Code:

  Status: "Idle."

Compare that to the same line in Tim's output.


What do you get in response to timedatectl? On my systems, which synchronized successfully, I see something like the following

Code:

pi@m833p3lcd:~ $ timedatectl
              Local time: Tue 2023-06-13 16:29:40 EDT
          Universal time: Tue 2023-06-13 20:29:40 UTC
                RTC time: n/a
               Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes
             NTP service: active
         RTC in local TZ: no

where the clock is reported to be synchronized and the NTP service is active.

Searching the InterWeb™, I found a similar problem reported by a Ubuntu user somewhere in the world. It was suggested by respondents that the system may be taking too long to find and synchronize with an authoritative time server. As distributed, the default timeout in moOde (e.g., RaspberryPiOS) is 5s. That should be plenty of time for most setups but apparently there are edge cases.

It was suggested to edit the /etc/systemd/timesyncd.conf file to uncomment the #RootDistanceMaxSec=5 line and increase the timeout value from 5 to, say, 15.

It can't hurt to try; you can always change it back it if doesn't work.

Regards,
Kent

[Nutul]

Check the time sync service from command line. If it is not able to connect to Internet time servers there should be some errors.

Command

Code:

systemctl status systemd-timesyncd

Here's what I get plus proof the internet is fine:

Code:

pi@electro:~ $ systemctl status systemd-timesyncd
● systemd-timesyncd.service - Network Time Synchronization
    Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
    Active: active (running) since Tue 2023-06-06 18:22:54 BST; 30s ago
      Docs: man:systemd-timesyncd.service(8)
  Main PID: 1039 (systemd-timesyn)
    Status: "Idle."
     Tasks: 2 (limit: 2137)
       CPU: 120ms
    CGroup: /system.slice/systemd-timesyncd.service
            └─1039 /lib/systemd/systemd-timesyncd

Jun 06 18:22:54 electro systemd[1]: Starting Network Time Synchronization...
Jun 06 18:22:54 electro systemd[1]: Started Network Time Synchronization.
Jun 06 18:23:04 electro systemd-timesyncd[1039]: Timed out waiting for reply from 192.168.4.1:123 (192.168.4.1).

pi@electro:~ $ date
Tue 06 Jun 2023 06:23:35 PM BST

pi@electro:~ $ wget www.bbc.co.uk
--2023-06-06 18:26:29--  http://www.bbc.co.uk/
Resolving www.bbc.co.uk (www.bbc.co.uk)... 212.58.235.1, 212.58.237.129, 212.58.236.1, ...
Connecting to www.bbc.co.uk (www.bbc.co.uk)|212.58.235.1|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://www.bbc.co.uk/ [following]
--2023-06-06 18:26:29--  https://www.bbc.co.uk/
Connecting to www.bbc.co.uk (www.bbc.co.uk)|212.58.235.1|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 604140 (590K) [text/html]
Saving to: ‘index.html’

index.html                                            100%[=======================================================================================================================>] 589.98K  --.-KB/s    in 0.09s    

2023-06-06 18:26:30 (6.73 MB/s) - ‘index.html’ saved [604140/604140]

Jun 06 18:23:04 electro systemd-timesyncd[1039]: Timed out waiting for reply from 192.168.4.1:123 (192.168.4.1).

Looks like your time-server is in your local network, like I use to do on my KODI box (I tell it the time server is my router...)
Nevertheless, it times out => no time-sync.

[Sehnsucht]

What do you get in response to timedatectl? On my systems, which synchronized successfully, I see something like the following

Code:

pi@m833p3lcd:~ $ timedatectl
              Local time: Tue 2023-06-13 16:29:40 EDT
          Universal time: Tue 2023-06-13 20:29:40 UTC
                RTC time: n/a
               Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes
             NTP service: active
         RTC in local TZ: no

where the clock is reported to be synchronized and the NTP service is active.

I get:

Code:

             Local time: Tue 2023-06-06 18:44:10 BST
          Universal time: Tue 2023-06-06 17:44:10 UTC
                RTC time: n/a
               Time zone: Europe/London (BST, +0100)
System clock synchronized: no
             NTP service: active
         RTC in local TZ: no

Searching the InterWeb™, I found a similar problem reported by a Ubuntu user somewhere in the world. It was suggested by respondents that the system may be taking too long to find and synchronize with an authoritative time server. As distributed, the default timeout in moOde (e.g., RaspberryPiOS) is 5s. That should be plenty of time for most setups but apparently there are edge cases.

It was suggested to edit the /etc/systemd/timesyncd.conf file to uncomment the #RootDistanceMaxSec=5 line and increase the timeout value from 5 to, say, 15.

I just tried a few, ending up with a value of 25.  I rebooted after each change and waited a while, but no change.   I tried stopping and starting systemd-timesyncd and it started showing Idle. before my 25 seconds were up.

I kept digging/experimenting and it turns out the fix is to edit /etc/systemd/timesyncd.conf and set NTP to have the content of the FallbackNTP line:
NTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org

Perhaps this should be the default for moOde installs if there's no downsides? Or perhaps keep the NTP line commented and simply uncomment the FallbackNTP line?

Edit: Nope, I tried this on my other moOde box.  I guess you have to set NTP not FallbackNTP because moOde thinks the one it's found (outside of this config file) is good enough to not need to fallback to anything, despite the "Idle." clue. 

Jun 06 18:23:04 electro systemd-timesyncd[1039]: Timed out waiting for reply from 192.168.4.1:123 (192.168.4.1).

Looks like your time-server is in your local network, like I use to do on my KODI box (I tell it the time server is my router...)
Nevertheless, it times out => no time-sync.

That IP address is my gateway - an EERO router.   I've had it a few months - it's pretty good.  It's possible the time on moOde has been wrong since then.   I see nothing in the EERO config (an android app) pertaining to ntp/time servers, nor do I see much on the subject when I google.  My other devices (linux desktop, chromebook, windows laptops, assorted phones/tablets) all show the correct time.

[TheOldPresbyope]

Actually, I see a smattering of seemingly related posts on the InterWeb™ regarding eero (especially with eero Secure) but I'm not in a position to comment. For a time in the past, I was on an ISP-provided eero mesh network and had no problem with moOde and time synchronization. That was then and this is now. Lots of changes have occurred in all of the components involved.

In any case, this is an issue between eero and Raspberry Pi OS; moOde is just going along on the ride. I suppose the moOde build could override the default /etc/systemd/timesyncd.conf file, but I'm not certain what the best settings would be. AFAIK the default settings allow each installation to find the closest available NTP server and this change would override that behavior. For the vast majority of us, the default settings work fine.

I'm not able to experiment with this for now. My partner and I fly to California in 10 hours to spend a couple of weeks with her new grandchild. That is a more exciting prospect than futzing with code

Regards,
Kent