astroarch
astroarch copied to clipboard
devDucks
AstroArch-1.8 @ RasPi4: should adopt timezone, date and time when it connects a network
When a RasPi4 connects a network (LAN, WLAN, WiFi) it should adopt its timezone, date and time like Astroberry @ RasPi4 does.
when connected to the network it does what reported, it may take longer times for clocks that are way off but eventually it will sync. How long you waited ?
I have the same issue. I had to resort to setting the date and time manually via the terminal. I tried using timedatectl but no luck, so I used sudo date -s to set it. Could never get it to do it automatically. Every time I turn on the pi, the date defaults to March 4th.
@gilbertgit would you send me the result of sudo systemctl status chronyd?
Also, what kind of network you use?
@MattBlack85 - The command sudo systemctl status chronyd yields this output on my RasPi4 for me:
○ chronyd.service - NTP client/server Loaded: loaded (/usr/lib/systemd/system/chronyd.service; disabled; preset: disabled) Active: inactive (dead) Docs: man:chronyd(8) man:chrony.conf(5)
@sophisticatedDreamer ah that would explain why time doesn't sync although it is weird it is disabled, can you try to enable it back by running sudo systemctl enable --now chronyd amd see if it sync?
In theory it should survive a reboot but what's more strange is that the service is enabled out of the box and I am unsure why it is disabled
By the way, after re-flashing and re-launching AstroArch (AA), I had to plug it to an Ethernet cable to configure the WiFi. Because it was plugged to a cable, date/time was immediately adopted from the LAN.
I had expected this same behavior when using WiFi.
@MattBlack85 - I agree ... setting a system service with systemctl enable .... sevice is the command to letting the service survive a reboot.
I will now shutdown AA@RasPi4 for a couple of hours and reboot it then. It should then adopt time/date immediately from WiFi as expected ...
Yeah, that was the problem. The service was disabled! I sudo systemctl enable and sudo systemctl start and it got the datetime right away! I did a reboot of the pi and it booted back up with the correct datetime. Thank you for your help!
I will now shutdown AA@RasPi4 for a couple of hours and reboot it then. It should then adopt time/date immediately from WiFi as expected ...
No matter what and how often I do, sudo systemctl enable (should survive reboot) and sudo systemctl start never survive a reboot. Seems that time/date from the last shutdown are stored and reused after next reboot, even hours later, with no automatic update.
I know timesyncd renders chrony dead, maybe that is enabled? can you check kindly @sophisticatedDreamer if sudo systemctl status systemd-timesyncd reports the service active by any chance?
>>> SEE UPDATE FURTHER DOWN <<<
I know timesyncd renders chrony dead, maybe that is enabled? can you check kindly @sophisticatedDreamer if
sudo systemctl status systemd-timesyncdreports the service active by any chance?
Sure:
○ systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; preset: enabled)
Active: inactive (dead)
Docs: man:systemd-timesyncd.service(8)
Though enabled timesyncd doesn't appear in the processes' list:
ps ax|egrep "d$"
194 ? Ss 0:00 /usr/lib/systemd/systemd-journald
234 ? Ss 0:00 /usr/lib/systemd/systemd-udevd
242 ? Ss 0:00 /usr/lib/systemd/systemd-networkd
322 ? Ss 0:00 /usr/lib/systemd/systemd-resolved
347 ? Ss 0:00 /usr/lib/systemd/systemd-logind
364 ? S 0:00 /usr/bin/chronyd
448 ? Ssl 0:00 /usr/lib/kglobalacceld
520 ? Ssl 0:00 /usr/lib/udisks2/udisksd
577 ? Ssl 0:00 /usr/lib/upowerd
592 ? Ssl 0:00 /usr/lib/kactivitymanagerd
1120 ? S 0:00 smbd: cleanupd
1265 ? Ssl 0:00 /usr/lib/packagekitd
>>> UPDATE (important) <<<
Out of curiousity I launched systemd-timesyncd manually - because it was already enabled (see above) but not running:
sudo systemctl start systemd-timesyncd
... and automatic network time/date synchronisation happened immediately after the next reboot, when I logged into AstroArch as fast as I could via SSH. When I then continued to log in via VNC (right after my SSH check), the time was again way off in the desktop panel ... but synchronizes a short while later without interaction.
Off topic: I had to edit my former post because clicking the [Code] button to format code, only sets one backtick around the pasted code while three backticks are required to get the right formatting.
@sophisticatedDreamer yes, i would expect timesyncd to work equally well if chrony is not active. From what i remember some people using mobile network routers were having issues with time syncing and we switched to chrony, but I am open to change to whatever works for everyone
One lastr trial could be the following:
- disable timesyncd (seems it is enabled but dead and it's weird cause of this https://github.com/devDucks/astroarch/blob/main/astroarch_build.sh#L93) enabling chrony
check if that works
>>> SEE UPDATE FURTHER DOWN <<<
Note that both are enabled but preset: disabled is set for chronyd while preset: enabled is set for timesyncd .... which shouldn't matter in this case, IMO.
sudo systemctl status systemd-timesyncd astronaut@astroarch
○ systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; preset: enabled)
Active: inactive (dead)
Docs: man:systemd-timesyncd.service(8)
------------------------------------------------------------------------------------------------------------------------------------------------------------------
~ » sudo systemctl status chronyd 4 ↵ astronaut@astroarch
● chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; preset: disabled)
Active: active (running) since Tue 2024-03-05 02:41:23 CET; 2 months 8 days ago
Docs: man:chronyd(8)
man:chrony.conf(5)
Process: 345 ExecStart=/usr/bin/chronyd $OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 365 (chronyd)
Tasks: 1 (limit: 8528)
CPU: 100ms
CGroup: /system.slice/chronyd.service
└─365 /usr/bin/chronyd
May 13 15:16:13 astroarch chronyd[365]: System clock was stepped by 6003256.849491 seconds
May 13 15:16:13 astroarch chronyd[365]: System clock TAI offset set to 37 seconds
May 13 15:17:19 astroarch chronyd[365]: Selected source 78.46.102.180 (2.arch.pool.ntp.org)
------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>> UPDATE <<<
Here is the same diagnosis after the changes you requested were applied. Please note that chrony believes the date/time to be Mar 05 02:41:19 over and over again, for an unknown reason.
sudo systemctl status systemd-timesyncd astronaut@astroarch
○ systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; disabled; preset: enabled)
Active: inactive (dead)
Docs: man:systemd-timesyncd.service(8)
------------------------------------------------------------------------------------------------------------------------------------------------------------------
~ » sudo systemctl status chronyd 3 ↵ astronaut@astroarch
● chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; preset: disabled)
Active: active (running) since Tue 2024-03-05 02:41:19 CET; 2 months 8 days ago
Docs: man:chronyd(8)
man:chrony.conf(5)
Process: 341 ExecStart=/usr/bin/chronyd $OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 361 (chronyd)
Tasks: 1 (limit: 8528)
CPU: 110ms
CGroup: /system.slice/chronyd.service
└─361 /usr/bin/chronyd
Mar 05 02:41:19 astroarch systemd[1]: Starting NTP client/server...
Mar 05 02:41:19 astroarch (chronyd)[341]: chronyd.service: Referenced but unset environment variable evaluates to an empty string: OPTIONS
Mar 05 02:41:19 astroarch chronyd[361]: chronyd version 4.5 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 -DEBUG)
Mar 05 02:41:19 astroarch chronyd[361]: Frequency 7.113 +/- 4.639 ppm read from /var/lib/chrony/drift
Mar 05 02:41:19 astroarch chronyd[361]: Using right/UTC timezone to obtain leap second data
Mar 05 02:41:19 astroarch systemd[1]: Started NTP client/server.
Mar 05 02:41:54 astroarch chronyd[361]: Selected source 141.82.25.203 (2.arch.pool.ntp.org)
Mar 05 02:41:54 astroarch chronyd[361]: System clock wrong by 6004358.577889 seconds
May 13 15:34:32 astroarch chronyd[361]: System clock was stepped by 6004358.577889 seconds
May 13 15:34:32 astroarch chronyd[361]: System clock TAI offset set to 37 seconds
------------------------------------------------------------------------------------------------------------------------------------------------------------------
BTW: The VNC Desktop adopts the current date/time after ~10s now.
the date from march is I believe the date I baked the image, wondering if a hwclock would move that to a more recent date
as discovered by @sc74 trying to change the time from Plasma was causing chrony to disable and additionally it wasn't even working - this should be fixed in 1.9.
Feel free to re-open should it be still broken