DietPi
DietPi copied to clipboard
MichaIng
Time Server Issue in China
Creating a bug report/issue
- [x] I have searched the existing open and closed issues
Required Information
-
DietPi version |
cat /boot/dietpi/.version-G_DIETPI_VERSION_CORE=8 G_DIETPI_VERSION_SUB=10 G_DIETPI_VERSION_RC=2 G_GITBRANCH='master' G_GITOWNER='MichaIng' -
Distro version |
echo $G_DISTRO_NAME $G_RASPBIANbullseye 0 -
Kernel version |
uname -aLinux rooExtend 5.15.61-v8+ #1579 SMP PREEMPT Fri Aug 26 11:16:44 BST 2022 aarch64 GNU/Linux -
SBC model |
echo $G_HW_MODEL_NAMEor (EG: RPi3) RPi 4 Model B (aarch64) -
Power supply used | (EG: 5V 1A RAVpower) 5V 1A
-
SD card used | (EG: SanDisk ultra) Sandisk Ultra
Additional Information (if applicable)
- Software title | (EG: Nextcloud)
- Was the software title installed freshly or updated/migrated? Fresh
- Can this issue be replicated on a fresh installation of DietPi? Yes
- Bug report ID |
echo $G_HW_UUID
Steps to reproduce
One of my customers live in China and the time in his system was wrong as the debian time servers can not be accessed. I added Chinese time servers in /etc/systemd/timesyncd.conf. In the attached dialog you can see that this did not help.
Any idea would be appreciated :-)
Expected behaviour
- ...
Actual behaviour
- ...
Extra details
- ...
The Great Firewall looks so arbitrary, contradicting and often nonsensical to me 😄. As the China NTP pool obviously is blocked as well, for whatever reason, you (your customer) need to find and use an NTP server which does work. This can be also the LAN router (or the ISP NTP server directly), which often uses the ISP NTP server, which is then probably the only non-blocked NTP server.
EDIT: It might be also just overloaded: https://community.ntppool.org/t/cn-pool-collapse-a-few-hours-every-day/3225
Sounds like something which should work, but I have no experience with NTP servers in China. When I was there, I just kept using what the OS offered.
Did not work :-(
I wonder if the Router offers a NTP server and how this can be used by timesyncd as default if available?
Of course you can set the router/gateway as NTP server within DietPi. We offer this option already. At least as long as the router supports NTP server function.
My goal is to ask the router first and if this did not work ask the debian NTP servers. Hope this will work in Mainland China too as the debian NTP servers and also the Pool only delibver timeout.
The first one in dietpi-config > Network Options: Misc > NTP Mirror:
┌──────────────────────────────────────────────────┤ DietPi-Config ├───────────────────────────────────────────────────┐
│ Please select an NTP mirror: │
│ │
│ "Gateway": Try to detect and use local router for time sync. Recommended, allows fastest sync and reduces load to │
│ the *.pool.ntp.org servers. │
│ │
│ "Custom": Manually enter local or external NTP server address(es). │
│ │
│ "Default": Leave mirror choice to system. Usually falls back to local gateway (Stretch+ only) or │
│ "debian.pool.ntp.org". │
│ │
│ Use "*.pool.ntp.org" mirrors, if your device is mobile or should act as local NTP server. Further information: │
│ "http://www.pool.ntp.org/zone/@" │
│ │
│ Gateway : Use local router as NTP server (Recommended) │
│ Custom : Manually enter NTP mirror │
│ Default : Fallback to system defaults │
│ ●─ Continental NTP pools ────────────────────● │
or
G_CONFIG_INJECT 'CONFIG_NTP_MIRROR=' 'CONFIG_NTP_MIRROR=gateway' /boot/dietpi.txt
/boot/dietpi/func/dietpi-set_software ntpd-mode
But not every router supports this.
The Debian NTP pool servers are used by default as fallback, but the fallback is only effective when other NTP servers are applied per-interface via systemd-networkd only, not when defining any NTP server via NTP= setting. There is sadly no way I am aware of to have a fallback like "try this first, and if it fails try the other".
I replaced the line in the dietpi.txt. Please take a look at my protocols. Do I interpret it correctly that this means he tries getting it from my Router (Apr 09 16:13:19) got a timeout and next tried to get it from debian (Apr 09 16:14:13)? If yes this might be a solution 👍
root@rooExtend:/home/pi# timedatectl timesync-status
Server: n/a (0.debian.pool.ntp.org)
Poll interval: 0 (min: 32s; max 34min 8s)
Packet count: 0
root@rooExtend:/home/pi# timedatectl status
Local time: Tue 2024-04-09 16:15:05 CEST
Universal time: Tue 2024-04-09 14:15:05 UTC
RTC time: n/a
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
root@rooExtend:/home/pi# timedatectl show-timesync --all
LinkNTPServers=
SystemNTPServers=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
FallbackNTPServers=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
ServerName=0.debian.pool.ntp.org
ServerAddress=213.209.109.45
RootDistanceMaxUSec=5s
PollIntervalMinUSec=32s
PollIntervalMaxUSec=34min 8s
PollIntervalUSec=1min 4s
NTPMessage={ Leap=0, Version=4, Mode=4, Stratum=2, Precision=-24, RootDelay=335us, RootDispersion=9.124ms, Reference=A810960, OriginateTimestamp=Tue 2024-04-09 16:14:49 CEST, ReceiveTimestamp=Tue 2024-04-09 16:14:49 CEST, TransmitTimestamp=Tue 2024-04-09 16:14:49 CEST, DestinationTimestamp=Tue 2024-04-09 16:14:49 CEST, Ignored=no PacketCount=1, Jitter=0 }
Frequency=0
root@rooExtend:/home/pi# journalctl -eu systemd-timesyncd
-- Journal begins at Tue 2024-04-09 16:13:18 CEST, ends at Tue 2024-04-09 16:15:35 CEST. --
Apr 09 16:13:19 rooExtend systemd[1]: Starting Network Time Synchronization...
Apr 09 16:13:19 rooExtend systemd[1]: Started Network Time Synchronization.
Apr 09 16:14:13 rooExtend systemd-timesyncd[286]: Initial synchronization to time server 80.60.67.39:123 (2.debian.pool.ntp.org).
Apr 09 16:14:13 rooExtend systemd[1]: Stopping Network Time Synchronization...
Apr 09 16:14:13 rooExtend systemd[1]: systemd-timesyncd.service: Succeeded.
Apr 09 16:14:13 rooExtend systemd[1]: Stopped Network Time Synchronization.
Apr 09 16:14:49 rooExtend systemd[1]: Starting Network Time Synchronization...
Apr 09 16:14:49 rooExtend systemd[1]: Started Network Time Synchronization.
Apr 09 16:14:49 rooExtend systemd-timesyncd[1840]: Initial synchronization to time server 213.209.109.45:123 (0.debian.pool.ntp.org).
root@rooExtend:/home/pi# cat /boot/dietpi.txt | grep CONFIG_NTP_MIRROR
#CONFIG_NTP_MIRROR=debian.pool.ntp.org
CONFIG_NTP_MIRROR=gateway
Note that editing dietpi.txt only has no effect. You need to run the 2nd command from my post above which applies the actual current gateway/default route as NTP server to /etc/systemd/timesyncd.conf. The dietpi.txt setting in this case acts for like a flag, or a choice for the backend script to use.
Actually, choosing "Default", respectively leaving the NTP settings completely untouched (removing the /etc/systemd/timesyncd.conf file) should be closest to what you want, if DHCP is used:
systemd-timesyncdapplies NTP servers provided via DHCP automatically via/etc/dhcp/dhclient-exit-hooks.d/timesyncd. If the router provides NTP functionality, I would expect it to promote this via DHCP as well.- If no NTP server is provided via DHCP,
systemd-timesyncduses the Debian NTP pool as fallback by default. WithFallbackNTPServers=this can be changed, but we currently have nodietpi-configway to set this, hence this would require a custom/etc/systemd/timesyncd.conf.
If no DHCP is used, I see no way to have a fallback functionality, but it must be tested manually.
Great, thank you 👍 OK, set it to "Default" now and see this: The config file had disappeared but still no hint that it tried to get data from the Router first. Sure, my Router delivers nothing so I would expect to see a timeout somewhere...
root@rooExtend:/home/pi# journalctl -eu systemd-timesyncd
-- Journal begins at Tue 2024-04-09 16:35:51 CEST, ends at Tue 2024-04-09 16:36:55 CEST. --
Apr 09 16:35:52 rooExtend systemd[1]: Starting Network Time Synchronization...
Apr 09 16:35:52 rooExtend systemd[1]: Started Network Time Synchronization.
Apr 09 16:36:48 rooExtend systemd-timesyncd[272]: Initial synchronization to time server 5.39.184.5:123 (2.debian.pool.ntp.org).
Apr 09 16:36:48 rooExtend systemd[1]: Stopping Network Time Synchronization...
Apr 09 16:36:48 rooExtend systemd[1]: systemd-timesyncd.service: Succeeded.
Apr 09 16:36:48 rooExtend systemd[1]: Stopped Network Time Synchronization.
root@rooExtend:/home/pi# cat /etc/systemd/timesyncd.conf
cat: /etc/systemd/timesyncd.conf: No such file or directory
root@rooExtend:/home/pi# timedatectl show-timesync --all
LinkNTPServers=
SystemNTPServers=
FallbackNTPServers=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
ServerName=0.debian.pool.ntp.org
ServerAddress=(null)
RootDistanceMaxUSec=5s
PollIntervalMinUSec=32s
PollIntervalMaxUSec=34min 8s
PollIntervalUSec=0
Frequency=0
root@rooExtend:/home/pi#
Then the router does not provide any NTP server via DHCP. It would be listed in:
cat /var/lib/dhcp/dhclient.*.leases
/var/lib/dhcp/dhclient.*.leases does not exist on my system.
But I use DHCP to get the IP for my Raspberry...
The * is a wildcard for the network interface. So it would be e.g. /var/lib/dhcp/dhclient.eth0.leases. If no such exists, your system does at least not use isc-dhcp-client/dhclient started from ifupdown as DHCP client, or it failed to receive any DHCP lease (which would usually mean no network).
You could explicitly set router IP as NTP target. This would work around any DHCP features
Indeed, but then the fallback feature does not work anymore, i.e. it is not a good default when providing images for customers 🤔.
ls -al /var/lib/dhcp/
total 8
drwxr-xr-x 2 root root 4096 Nov 17 2022 .
drwxr-xr-x 29 root root 4096 Feb 11 2023 ..
This is empty. But the installation gets IP by DHCP. Maybe I use a different client? Can't remember. Setting the Router IP is not a good choice as it changes from Client to client.
But as far as I understood after deleting /etc/systemd/timesyncd.conf the NTP from the Router is checked first and then debian will be asked. Right? This is what I think is a good choice.
My Rouder did not provide NTP so I expected to see a timeout before debian got asked. If I enter a fixed IP of the Router I get a timeout and no debian request.
But as far as I understood after deleting
/etc/systemd/timesyncd.confthe NTP from the Router is checked first and then debian will be asked. Right? This is what I think is a good choice.
Without the file, the NTP provided by the router via DHCP is used, if present in the lease, else the Debian NTP pool is used. There is no fallback after timeout, it is always only 1 single server or pool tried. But this only works if either systemd-networkd or isc-dhcp-client/dhclient are used as DHCP client. systemd-timesyncd seems to have no hook for other DHCP clients like dhcpcd: https://packages.debian.org/bookworm/amd64/systemd-timesyncd/filelist
E.g. htop should show the DHCP client process, or
ps aux | grep '[d]hcp'
... actually, not a fallback, but another way would be to add a pool + the router IP to the same NTP= line. It is usually meant to be used for multiple instances of an NTP pool, but in the end, AFAIK, systemd-timesyncd just sends an NTP request to all listed servers and takes the first response. This does not rely on DHCP or any specific DHCP client. From the perspective of NTP pool operators, it isn't ideal, as their pool is (ab)used even if the router does provide NTP functionality. But for edge cases where the router does provide NTP functionality, but for whatever reason does not send it via DHCP, or no supported DHCP client is used, it is handy. Also, probably it is not as bad when defining the router IP in the front of the NTP pool hostnames. On the man page it says that systemd-timesyncd "contact all configured system or per-interface servers in turn, until one responds". Probably it gives each a little time before contacting the next, and the router should answer pretty fast, if it has NTP functionality.
Ok, dhcpcd is running 👎
So the question is how to get the IP number of the Router plus the name of the Pool in the file?
This must be ready before systemd-timesyncd runs for the first time???
This must be ready before
systemd-timesyncdruns for the first time???
You could do this via dietpi.txt, but you must know the router IP first:
CONFIG_NTP_MIRROR=192.168.1.1 debian.pool.ntp.org
If this turns out to work nicely, and does not call all 4 pool servers on every sync, despite the router answering first/fast, I'll add some native setting for this, so that you can use:
CONFIG_NTP_MIRROR=gateway debian.pool.ntp.org
Uff, I see this section's comments are pretty outdated, talking about /etc/ntp.conf, and default is not the default 😄.
EDIT: Better: https://github.com/MichaIng/DietPi/commit/0283693