search

MichaIng / DietPi

Lightweight justice for your single-board computer!
https://dietpi.com/
GNU General Public License v2.0
4.92k stars 501 forks source link

Time stops - Pi-hole - unbound - time: Fix DNSSEC problems after power loss #6684

Open pipapoquant opened 1 year ago

pipapoquant commented 1 year ago

Creating a bug report/issue

Required Information

RPi 400 (aarch64)

Additional Information (if applicable)

Pi-hole, unbound, DNSSEC, time stops

Expected behaviour

correct time on every startup

Actual behaviour

Dietpi with Pi-hole and unbound ---> time stops after switch off

time loss after power loss / switch off

For the authentication process in DNSSEC, the time must be accurate...

I switch off both: my WLAN-internet-router and Raspberry Pi 400 over night to save power and to reduce radiation. I don't use a real-time-clock.

My router is configured to act as NTP-server.

When I start both: the Raspberry and the WLAN-router with a multipoint connector it takes some minutes until I get an internet connection.

Unfortunately my Raspberry Pi 400 obtains the wrong time.

In the event of a power outage, the time remains approximately the same as at the time of the power outage. When querying the stored time servers, BOGUS DNSSEC messages are generated due to the time deviation and the NTP domain is not resolved to the corresponding IP address. The time of the pi-hole cannot be synchronized and all DNS requests of the clients are answered with BOGUS.

I would like to set the clock each time I switch on Raspberry Pi 400 with pi-hole.

For this reason I edited the timesyncd.conf as described in the following manual:

sudo nano /etc/systemd/timesyncd.conf

NTP=

FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org

RootDistanceMaxSec=5

PollIntervalMinSec=32

PollIntervalMaxSec=2048

NTP=192.168.50.1

The latter entry is the address of my router.

The timesync daemon is then restarted with:

systemctl restart systemd-timesyncd.service

Then I check whether the stored NTP server is used for the time query and obtain an error message:

timedatectl timesync-status

“Failed to connect to bus: Datei oder Verzeichnis nicht gefunden”

That means: “Didn’t find file or folder.”

Please advise, how to solve the problems in Diet-Pi.

For security reasons the above mentioned manual suggests to amend the /etc/crontab to force a time synchronization after a restart:

sudo nano /etc/crontab

@reboot root timedatectl set-ntp true

Where and how can I configure something like this within Diet Pi, because it’s different?

Many thanks for your hints!

Joulinar commented 1 year ago

Unfortunately my Raspberry Pi 400 obtains the wrong time.

On reboot, the system will take initial system time from a saved time point. We usually created this backup time once an hour at the 17th minute or on regular shutdown/reboot.

“Failed to connect to bus: Datei oder Verzeichnis nicht gefunden”

We don't install dbus by default. However you can do that manually.

I would like to set the clock each time I switch on Raspberry

on a default configuration, DietPi will try to perform a time sync with configured NTP server on reboot automatically. This could take up to 1 minute.

Please advise, how to solve the problems in Diet-Pi.

Did you already tried to configure your Gateway/Router as regular NTP server

dietpi-config > 8 : Network Options: Misc > NTP Mirror > Gateway

Ater reboot, you can check NTP time sync logs as follow

journalctl -u systemd-timesyncd.service

Btw, what DNS server you configured within DietPi?? Do you use PiHole itself or a global public DNS provider?

cat /etc/resolv.conf

Best practice is not to use PiHole on local DietPi settigs as this could lead to several issues.

pipapoquant commented 1 year ago

Problem is known and solved within Raspberry OS by hints of: https://www.kuketz-blog.de/pi-hole-uhrzeit-dnssec-probleme-nach-stromverlust-beheben/

The Raspberry Pi should not have to resolve an NTP domain that is not answered due to the time difference in combination with DNSSEC.

The Raspberry Pi should make better use of the router's local IP address to synchronize its time.

Joulinar commented 1 year ago

yes, that's what I have stated above. Don't use PiHole as upstream DNS inside DietPi and go into DietPi settings to set your gateway as upstream NTP.

pipapoquant commented 1 year ago

I use pi-hole together with unbound. Everything works, if time is ok. But I switch the Raspberry Pi 400 off, when going to bed with the famous Fn + F10 key ---> a kind of hard switch off, because there is no screen. So the time next morning is wrong.

The router needs some minutes to connect to internet and get the time from an external NTP-Server. Router and pi-hole and unbound are linked as described in the manuals.

All people, who switch off the Raspberry Pi and the router during the night, face the same problems. For this reason I would like to amend some settings within DietPi as described in the manual of Mike Kuketz (cnf. the mentioned link).

It would be great, if you could give us a hint where and how to install / type in something like the:

sudo nano /etc/crontab

@reboot root    timedatectl set-ntp true

on a default configuration, DietPi will try to perform a time sync with configured NTP server on reboot automatically. This could take up to 1 minute.

Where can I amend this? I edited:

sudo nano /etc/systemd/timesyncd.conf

and added the local address of my router, which acts as a NTP-Server. To do this, the router needs an internet-connection. This takes some minutes (over the air, mobile-provider) and could also cause problems.

If DietPi looks for an NTP-Server for 1 minute only, this won't be enough. DietPi should look at least for 6 minutes to get the time fixed, because the internet-connection needs time.

Joulinar commented 1 year ago

I shared above how you can set your local router as NTP server.

As well I recommend not to set PiHole as local upstream DNS inside DietPi

Did you checked what I have stated above?

pipapoquant commented 1 year ago

I checked the following in DietPi:

dietpi-config > 8 : Network Options: Misc > NTP Mirror > Gateway

Yes, my router was selected (=Gateway).

cat /etc/resolv.conf

= IP-V4-address of my router

In Pi-hole I checked Upstream DNS Servers via the web-interface:

Custom 1 is checked = 127.0.0.1#5335

In my router the DNS entry is the IPV4-address of my Raspberry Pi 400 with DietPi-PiHole

Really strange: I saw after the update of my router-firmware, that they checked IPV6-DNS to be delivered by my internet-provider.... When I set up Pi-Hole and Unbound once with the automatic setup via DietPi, this "feature" didn't exist in my router. I had to amend the DNS IP4-Server (address of my Raspberry Pi), only. I didn't do anything / configure in DietPi or elsewhere with DNS IP v 6....

Now I still stand here like a duck in a thunderstorm.

Please advise

Joulinar commented 1 year ago

You are mixing quite some topics in. Your router options are unrelated to DietPi or any software you install in DietPi. If there is a new IPv6 option in your router it was introduced by some software update of the router itself.

cat /etc/resolv.conf

= IP-V4-address of my router

Do you use Static IP address or DHCP? If Static, set it to a global upstream DNS instead of your router.

You should be fine if your router has been set as upstream NTP server. You should see the results after reboot by running

journalctl -u systemd-timesyncd.service

If you start both (router and DietPi) at the same moment, time sync might not succeed in first place because your SBC will be way faster compared to your router. There is no chance for your SBC to get a valid time until the router is fully online. However you should see that within logs as stated above.

pipapoquant commented 1 year ago

cat /etc/resolv.conf

I used the Static IP - address of my router. A misconfiguration ? Perhaps, because in my router is entered the local DNS = Raspberry Pi - IPv4-address AND at DNS-IPv6: "use the server of my internet-provider"... So I changed DNS-Server in the Network Options of DietPi to the static IPv4-address of my Raspberry Pi as DNS-Server. Result: internet-connection still works.

If I would enter in the Network Options of DietPi a DNS of Google or whoever, I won't need Raspberry Pi with Pi-Hole and unbound to act as my own DNS resolver? I thought, using unbound would offer more privacy than global DNS-server.

Yes, I guess, that's one of the problems:  I  start both (router and DietPi) at the same moment by pressing the button on the multiple power socket. Could you give me a hint, how I could prolong the time, DietPi asks the NTP-server what's the time, please? My idea would be: DietPi starts... , time sync might not succeed in first place and stops for a minute. Then it asks again and again, until it gets an updated and correct time from my router as NTP-Server.... Only when DietPi gets the valid time it boots and everything would work.

I tried the following:

1) Unplugged the router and the Raspberry Pi from the same powercord. 2) Started the router and waited for an internet-connection. I waited about 2,5 minutes and the LEDs of the router stoped. So I expected an internet connetion. 3) Started Raspberry Pi with DietPi 4) Checked again

Report of the results: Debian GNU/Linux 11 Raspiname tty1 Raspiname login: ???????????????????? DiePi v 8.22.3 : 22:17 - Mo 16.10.2023 ??????????????????? Hit to login

I logged in. Still false time. I pressed Fn + F10 to shutdown (Works like a switch off -> not a soft shutdown .... Perhaps the DietPi-team will amend this in the future that Fn + F10 on Raspberry Pi 400 evokes a soft shutdown as in Raspberry Pi OS? ) I restarted by pressing F10 on Raspberry Pi 400.

Again false time.

I waited again and logged in.

Time was ok then.

Normally I won't log in, because Raspberry Pi is just a headless workhorse for pi-hole and unbound....

I checked NTP time sync logs:

journalctl -u systemd-timesyncd.service

At first 8:56 o'clock there was the correct entry:

8:56 #raspiname systemd-timesyncd[348]: Initial syncronization to time server [Router IPv4-address]

Take into account, that I started the router at 8:45 o'clock and waited about 2,5 minutes...

Please advise! Many thanks!

Joulinar commented 1 year ago

Changing the DNS server in dietpi-config has 0 effect on your network clients. This setting has nothing to do with the functionality of PiHole/Unbound. It is a setting for the DietPi system only and independent of the rest of your network. Nothing else. If PiHole/Unbound has problems resolving DNS requests, your DietPi system will still be able to do so because it uses a different DNS configuration.

Does the time sync at 8:56 o'clock succeed? It would be appreciated if you can share the entire log and not just single lines.

Btw it is not needed to restart the system again and again and again. Simply checking the time service should be sufficient.

pipapoquant commented 1 year ago

Yes, time sync at 8:56 o'clock succeeded. The entries before stated only the time of yesterday night ... 22:17 - Mo 16.10.23

So there is a difference of 11 minutes from router-start-time to initial synchronization to time server. And about 9 minutes difference from Raspberry Pi 400 start to initial synchronization to time server.

Maybe I should mention the orange highlighted question-marks on the login-screen, too.

The output of journalctl -u systemd-timesyncd.service

is a bit short. Could I type anything to show you the last days perhaps?

Joulinar commented 1 year ago

Usually logs are located on a temp file system. Means they will be lost on reboot.

Next morning you power on your router + SBC, wait a couple of minutes and run following

journalctl -u systemd-timesyncd.service
date

pls share the entire output.

pipapoquant commented 1 year ago

I exchanged the SD-card of my Raspberry Pi 400. In the meantime worked without problems with the new Raspberry Pi OS Lite Release date: October 10th 2023; System: 64-bit; Kernel version: 6.1 ; Debian version: 12 (bookworm) with pi-hole and unbound and the above mentioned amendments to obtain the time from my router....

I switched on the router at about 7 o'clock Wednesday morning, 18.10.2023 and waited for hours.

Everything was perfect with Raspberry Pi OS Lite bookworm!

The router was still running and I switched off Raspberry Pi 400 and inserted the DietPi-SD-Card.....

I started DietPi at about 11:58 o'clock.

Debian GNU/Linux 11 Raspiname tty1 Raspiname login .......

Dietpi v8.22.3: 14:17 - Di 17.10.2023 -Lan IP: static IP of my Raspberry Pi Please hit to login

So DietPI showed the wrong time on the login-screen.

Then I logged in and recognized the correct time:

12:02 - Mi 18.10.2023

journalctl -u systemd-timesyncd.service date

screenshotan2

Because I don't use ssh, I took a photo of the result.

Is it possible to amend DietPi that the correct time will be updated while booting / starting and will be displayed on the login-screen? Many thanks.

Joulinar commented 1 year ago

Time sync process is running in parallel to the login within background. Means, you will see the login screen way before the time has been synchronised. We do this to ensure faster startup process and not to wait for the time sync service to complete.

Incorrect time on login screen is cosmetic only. As you can see, time has been correct synchronized after startup.

MichaIng commented 1 year ago

I use pi-hole together with unbound. Everything works, if time is ok. But I switch the Raspberry Pi 400 off, when going to bed with the famous Fn + F10 key ---> a kind of hard switch off, because there is no screen. So the time next morning is wrong.

This is a problem: If you hold those keys for 10 seconds or more, this does a hard poweroff, like power cycling, which is dangerous as it can lead to data loss. If you hold it for less than 10 seconds (2 or more), it should do a smooth/regular shutdown, but AFAIK this feature needs logind and hence dbus. So if the smooth shutdown is not working, try:

systemctl unmask systemd-logind
apt install dbus
systemctl start systemd-logind

A regular shutdown also means that fake-hwclock is saving the current time to disk, to avoid the up to 1h missing system time. However, if you shutdown over night, this of course does not really matter, so a soft shutdown, while being reasonable/important, does not solve your particular issue.

Interesting fact that DNSSEC requires such a precise system. I think it makes sense as DNS records in general have a TTL of 1 day at most, often much shorter down to 1 minute. I do not see the TTL of our DS record (for DNSSEC), but I guess it makes sense that it is short, for its security purpose (EDIT: Ah, it is 1h in our case: https://dnsviz.net/d/dietpi.com/dnssec/). However, this is another good reason, as stated by Joulinar, to not use Pi-hole or Unbound as DNS resolver for the Pi-hole/Unbound server itself, but instead either your router (hence usual ISP DNS, but cached) or a trusted public DNS resolver, like Quad9 or Cloudflare. Since you usually have no desktop and browser installed on the Pi-hole server system, an ad and tracker blocker has no point. DNSSEC is still another security measure, but much less relevant for this system. However, if this is really wanted, then at least one time sync needs to be done at boot which bypasses DNSSEC, to break the chicken-and-egg issue.

Everything was perfect with Raspberry Pi OS Lite bookworm!

Of course it does, just like on DietPi. There is nothing done on any of both systems, nor by the Pi-hole installer, which would setup Pi-hole as resolver for its own host, because of exactly such issues. If your system was configured that way, then you either did so manually, or you did setup the system several years ago, when indeed the Pi-hole installer erroneously did setup itself as its own DNS resolver.

So after switching it that way, the issue is solved right?

Is it possible to amend DietPi that the correct time will be updated while booting / starting and will be displayed on the login-screen? Many thanks.

Actually the time in your login screen is correct, from after the successful time sync. However, the first time sync can take longer then the rest of the boot process, so that the login prompt shows up already. There is not really something we can do about it, and as stated by Joulinar, this is a visual quirk only.

pipapoquant commented 1 year ago

Thank you very much indeed for the dbus-hint concerning Fn + F10 ! Now the soft shutdown works like a "sudo poweroff" or "Sudo shutdown -h now" by pressing

1) Fn + F10 once for 1 second and then 2) Fn + F10 twice for 2 seconds....

without a computer screen connected to Raspberry Pi 400 next to the router.

If I try it only once by pressing for 2 or 3 seconds the Raspberry Pi 400 won't react. It seems that there are many users with this problem if I search in internet concerning this question.

Suggestion for DietPi-Installer in future DietPi-OS maybe:

The installer could ask the user, if he would like to install debus to be able to use the "Fn + 10 smooth shutdown" or if he uses a Raspberry Pi 400 or .... give a hint how to do this.

Are you sure, that the time on log-in-screen is just cosmetics? Most problems occurred in the past concerning the time-problems after a weekend or after holiday.

To break the chicken-and-egg issue:

Maybe a kind of "Network at Boot" could help? I mean an option in DietPi during the boot-process to wait for a valid network connection and a time-update from the router (Gateway) before letting DietPi-boot proceed. I guess there was something like this in Raspberry Pi OS, once upon a time.

I'll format my SD-card and start from the beginning with a clean, updated install of DietPi. Maybe we will achieve success this way.

Last point on my wish list ;-)
By the way another hint for all other people, who switch off router and Raspberry Pi over night... : Maybe you could let ask the installer of DietPi for amended cron-jobs .... ;-) to get updates during the day... By checking this and that concerning the time-problems I found out my blunder .... So I had to check for updates manually.

Again thank you very much indeed for developing DietPi and for your tireless efforts!

Joulinar commented 1 year ago

Are you sure, that the time on log-in-screen is just cosmetics?

Yes, login screen is displayed way before time sync completed. To give an example from one of my test systems OrangePi 5. This is a snip from system log journalctl showing the time sync process, network start up and reaching the point where the login screen is displayed. It's one log and I put it into smaller parts to get a better understanding.

Oct 07 13:51:21 DietPi systemd[1]: Stopping systemd-timesyncd.service - Network Time Synchronization...
Oct 07 13:51:21 DietPi systemd[1]: systemd-timesyncd.service: Deactivated successfully.
Oct 07 13:51:21 DietPi systemd[1]: Stopped systemd-timesyncd.service - Network Time Synchronization.
Oct 07 13:51:21 DietPi systemd[1]: Starting systemd-timesyncd.service - Network Time Synchronization...
Oct 07 13:51:21 DietPi systemd[1]: Started systemd-timesyncd.service - Network Time Synchronization.
Oct 07 13:51:22 DietPi dhclient[538]: bound to 192.168.0.145 -- renewal in 39276 seconds.
Oct 07 13:51:22 DietPi ifup[538]: bound to 192.168.0.145 -- renewal in 39276 seconds.
Oct 07 13:51:22 DietPi systemd[1]: Finished ifup@eth0.service - ifup for eth0.
Oct 07 13:51:22 DietPi systemd[1]: Reached target network.target - Network.
Oct 07 13:51:22 DietPi systemd[1]: Reached target network-online.target - Network is Online.
Oct 07 13:51:22 DietPi systemd[1]: Started dietpi-postboot.service - DietPi-PostBoot.
Oct 07 13:51:22 DietPi systemd[1]: Started dropbear.service - Lightweight SSH server.
Oct 07 13:51:22 DietPi systemd[1]: Started home-assistant.service - Home Assistant (DietPi).
Oct 07 13:51:22 DietPi dropbear[627]: [627] Oct 07 13:51:22 Failed loading /etc/dropbear/dropbear_dss_host_key
Oct 07 13:51:22 DietPi dropbear[627]: [627] Oct 07 13:51:22 Not backgrounding
Oct 07 13:51:22 DietPi systemd[1]: rsync.service - fast remote file copy program daemon was skipped because of an unmet condition check (ConditionPathExists=/etc/rsyncd.conf).
Oct 07 13:51:22 DietPi systemd[1]: Starting systemd-user-sessions.service - Permit User Sessions...
Oct 07 13:51:22 DietPi systemd[1]: Finished systemd-user-sessions.service - Permit User Sessions.
Oct 07 13:51:22 DietPi systemd[1]: Started getty@tty1.service - Getty on tty1.
Oct 07 13:51:22 DietPi systemd[1]: Started serial-getty@ttyFIQ0.service - Serial Getty on ttyFIQ0.
Oct 07 13:51:22 DietPi systemd[1]: Reached target getty.target - Login Prompts.
Oct 07 13:51:22 DietPi systemd[1]: Reached target multi-user.target - Multi-User System.
Oct 07 13:51:22 DietPi systemd[1]: Reached target graphical.target - Graphical Interface.
Oct 07 13:51:22 DietPi systemd[1]: Starting systemd-update-utmp-runlevel.service - Record Runlevel Change in UTMP...
Oct 07 13:51:22 DietPi systemd[1]: systemd-update-utmp-runlevel.service: Deactivated successfully.
Oct 07 13:51:22 DietPi systemd[1]: Finished systemd-update-utmp-runlevel.service - Record Runlevel Change in UTMP.
Oct 07 13:51:22 DietPi systemd[1]: Startup finished in 4.610s (kernel) + 9.604s (userspace) = 14.215s.
Oct 07 13:51:22 DietPi kernel: ttyFIQ ttyFIQ0: tty_port_close_start: tty->count = 1 port count = 2
Oct 19 12:35:15 DietPi systemd-timesyncd[603]: Contacted time server 188.68.41.203:123 (0.debian.pool.ntp.org).
Oct 19 12:35:15 DietPi systemd-timesyncd[603]: Initial clock synchronization to Thu 2023-10-19 12:35:15.923153 BST.
Oct 19 12:35:15 DietPi systemd[1]: Starting dpkg-db-backup.service - Daily dpkg database backup service...
Oct 19 12:35:15 DietPi systemd[1]: dpkg-db-backup.service: Deactivated successfully.
Oct 19 12:35:15 DietPi systemd[1]: Finished dpkg-db-backup.service - Daily dpkg database backup service.
Oct 19 12:35:16 DietPi systemd[1]: Stopping systemd-timesyncd.service - Network Time Synchronization...
Oct 19 12:35:16 DietPi systemd[1]: systemd-timesyncd.service: Deactivated successfully.
Oct 19 12:35:16 DietPi systemd[1]: Stopped systemd-timesyncd.service - Network Time Synchronization.
Joulinar commented 1 year ago

Maybe a kind of "Network at Boot" could help? I mean an option in DietPi during the boot-process to wait for a valid network connection and a time-update from the router (Gateway) before letting DietPi-boot proceed.

We had this behaviour in past where system time sync was holding back whole boot process. And do you know what happend? Quite a number of users complained about the long boot process and the system waiting on time sync ;)

The installer could ask the user, if he would like to install debus

Theoretically there is an option in dietpi.txt that could be set before initial boot/setup

https://github.com/MichaIng/DietPi/blob/fb0db339f63275d8924b80db7bca2d8d0410e6a0/dietpi.txt#L59-L60

Maybe you could let ask the installer of DietPi for amended cron-jobs

This can be done by running dietpi-cron. As well on reboot, system is going to check for available updates and will notify you during login.

pipapoquant commented 1 year ago

Maybe a kind of "Network at Boot" could help? I mean an option in DietPi during the boot-process to wait for a valid network connection and a time-update from the router (Gateway) before letting DietPi-boot proceed.

"We had this behaviour in past where system time sync was holding back whole boot process. And do you know what happend? Quite a number of users complained about the long boot process and the system waiting on time sync ;)"

That's funny....

May I suggest just an Network at Boot - option to do this in the DietPi-Installer or DietPi-config?

In Raspberry Pi OS raspi-config it was also just an optional feature. I can understand that's not wanted by anybody. And other users have the need to use this feature....

I would implement an option to this feature to boot anyway = to pull up and go round again, if the system hangs in case there won't be an Internet-connection. E.g. if the provider is down or why-ever there is no connection.

MichaIng commented 1 year ago

Generally we keep the config options in dietpi-installer minimal. It is not meant to be a pre-configuration tool, but a tool to create a minimal DietPi image from a Debian image. There are ideas to allow pre-installing software, which implies pre-configuration until a certain level, but that is not a high priority (for my own development time). You can use dietpi.txt to do a lot more pre-configuration and have things setup automatically on first boot.

May I suggest just an Network at Boot - option

As you can see from Joulinar's output, the dietpi-postboot service, which initiates the DietPi update check and checks for the time sync status, as well as the login prompt, and those software services which require network, are already waiting for network before starting. There is even an option for this in dietpi-config "Network Options: Misc" to control this for dietpi-postboot and login prompt. The DietPi update check internally does a network and time sync check/wait, of course, as without it, this was not possible, so basically you are controlling the login prompt and hence also the time of those dietpi-autostart options which imply autologin. The DietPi update check as well as the time sync check however run asynchronously, for mentioned reasons. Aside of some autostart options, only the LAN IP info on login prompt as well as some info of the DietPi banner after the login require network. None of them require a precise network time, and thanks to fake-hwclock, the offline system time is usually not further off then the time you had your SBC powered off. The chance that a new HTTPS certificate for one of the domains contacted by the DietPi banner or an autostart option, becomes valid within this time range, is extremely low.

Is there anything in particular now trying to start before the time sync finished, and failing because of that? I thought the chicken-and-egg issue between time sync and DNS resolving, again required for time sync, was the only issue? If the system (whichever part you mean exactly) would wait for time sync in this situation, it would wait forever. The duration is not the problem then, but that you cannot sync time via "pool.ntp.org" without being able to resolve "pool.ntp.org", which is again not possible without first syncing time via "pool.ntp.org" first, if this domain has a DS record 😉. Simply not using Unbound, hence not doing DNSSEC checks with the Pi-hole/Unbound host however solves this problem.

pipapoquant commented 1 year ago

Thank you very much, indeed, for the explanations. I formatted my SD-card, upgraded to the newest DietPi Bookworm release and set up DietPi, PiHole and Unbound from the beginning. It worked about a week - and on Sunday the same problems occurred. So I waited for about an hour without touching DietPi and my router ->> magic: PiHole-Unbound got the time and everything was fine. I checked the settings then in Dietpi-Config --> Time sync mode: It was set to "3" = Boot + Hourly.

Is it the best setting for people, who switch off their Mobile-Router and Raspberry Pi over night?

Or would you recommend another setting?

Where could I amend the settings to switch Time sync mode to Boot + "Every 15 minutes" ?

Maybe you could have a glance with an online-translator on:

[https://www.kuketz-blog.de/pi-hole-uhrzeit-dnssec-probleme-nach-stromverlust-beheben/]

where same problems are mentioned for Rasberry Pi OS.

Thanks a lot!

MichaIng commented 1 year ago

So I waited for about an hour without touching DietPi and my router ->> magic: PiHole-Unbound got the time and everything was fine.

It sounds like the network time sync failed at boot, and it did not succeed even until the dietpi-update check on triggered another time sync, which includes a 60 seconds timeout, before systemd-timesyncd is stopped. Then it takes until next hourly cron job for another time sync, which succeeded.

Would be interesting why it failed in the first place, as the dietpi-update check does a network connectivity check first, so the system as definitely online:

journalctl -u systemd-timesyncd

However, if this happens by time, better switch to "4 : Daemon + Drift". This way, systemd-timesyncd keeps running, and retrying faster if the first time sync fails. This also makes more sense than a "every 15 minutes" setting, since too regular wrapper script and server start and stops may lead to overall higher system load than just leaving the service up. But what could make sense is to implement a variable to change the time sync timeout for hourly/daily mode, and/or increasing it for the first time sync at boot, as this is the most important one.

Maybe you could have a glance with an online-translator on:

This is not required as long as you do not use Pi-hole or Unbound as DNS resolver for the host system itself. However, if you do, then you can archive this exact solution by selecting "Gateway" as NTP server in dietpi-config > "Network Options: Misc" > "NTP Mirror". Joulinar mentioned this above already. Not all routers have an NTP server installed (mine has not 😢), but if so, this is indeed the best solution in most cases (independently of the DNSSEC issue), since LAN clients do not need to do remote NTP requests but sync cheaply within you LAN and only the router syncs with a remote NTP server.

Joulinar commented 1 year ago

It sounds like the network time sync failed at boot, and it did not succeed even until the dietpi-update check on triggered another time sync, which includes a 60 seconds timeout, before systemd-timesyncd is stopped.

Yes because router and DietPi SBC are started at same time. Means DietPi is already up, while router still booting.

MichaIng commented 1 year ago

Yes because router and DietPi SBC are started at same time. Means DietPi is already up, while router still booting.

But why is the proceeding network connection check succeeding? I mean if that succeeds, I see no reason why the time sync would not. Ah, or if the router is used as NTP server already and it sets up Internet connectivity for clients (significantly) earlier than its NTP server? In this case, using a remote NTP server should solve it.

pipapoquant commented 1 year ago

...better switch to "4 : Daemon + Drift". This way, systemd-timesyncd keeps running, and retrying faster if the first time sync fails. This also makes more sense than a "every 15 minutes" setting, since too regular wrapper script and server start and stops may lead to overall higher system load than just leaving the service up. But what could make sense is to implement a variable to change the time sync timeout for hourly/daily mode, and/or increasing it for the first time sync at boot, as this is the most important one.

Could you give me any advice how to implement a variable and so on, since I don't have the foggiest idea ... Anyway I will switch on "4: Daemon + Drift" for some week(s) to test further.

If you start both (router and DietPi) at the same moment, time sync might not succeed in first place because your SBC will be way faster compared to your router. There is no chance for your SBC to get a valid time until the router is fully online.

I guess, that's the main problem. The router needs many minutes to get internet connection. In the meantime my SBC is booted.

...by selecting "Gateway" as NTP server in dietpi-config > "Network Options: Misc" > "NTP Mirror". Joulinar mentioned this above already. Not all routers have an NTP server installed (mine has not 😢), but if so, this is indeed the best solution in most cases (independently of the DNSSEC issue), since LAN clients do not need to do remote NTP requests but sync cheaply within you LAN and only the router syncs with a remote NTP server.

I use "Gateway", but there could be also another thing:

In my router is a field in which “0. europe. pool. ntp. org” is entered by default. Unfortunately, this server is - as the saying goes in Internet - also often unreachable. In addition I read, it would be better to use a timeserver as close as possible, which increases accuracy. And also not to use a pool, because they were lame and also built connections (NTP) to RU & UA (according to ntopng), not to mention data protection....

So I will amend this in my router.

Ah, or if the router is used as NTP server already and it sets up Internet connectivity for clients (significantly) earlier than its NTP server?

I don't know, when and how often my router obtains the time from the NTP-Server. I checked the records in my router:

screenshot_router

I tried to translate the messages (black, above screenshot) of the events yesterday.

Today (2023-11-06) DietPi got the time ! :-)

2023-11-06_router_screenshot

But anyway it seems, there is a problem in the morning with DNS over TLS (DoT).

I enabled in my router: DNS over TLS (DoT) Encrypted Name Resolution on the Internet (DNS over TLS): Check

Enforce certificate verification for encrypted name resolution on the Internet: Check

Yesterday I switched within DietPi-config to "4 : Daemon + Drift". Then I shut down DietPi after midnight. Raspberry Pi 400 and the router were switched on again together next morning:

# journalctl -u systemd-timesyncd.service
Nov 06 00:24:41 XYZ systemd[1]: Starting systemd-timesyncd.service - Network Time Synchronization...
Nov 06 00:24:41 XYZ systemd[1]: Started systemd-timesyncd.service - Network Time Synchronization.
Nov 06 00:25:23 XYZ systemd-timesyncd[311]: Timed out waiting for reply from [IP-address of my router]:123 ([IP-address of my router]).
Nov 06 00:26:38 XYZ systemd-timesyncd[311]: Timed out waiting for reply from [IP-address of my router]:123 ([IP-address of my router]).
Nov 06 06:35:27 XYZ systemd-timesyncd[311]: Contacted time server [IP-address of my router]:123 ([IP-address of my router]).
Nov 06 06:35:27 XYZ systemd-timesyncd[311]: Initial clock synchronization to Mon 2023-11-06 06:35:27.290021 CET.

I will check the logs again, if/when DietPi pi-hole, unbound hang as yesterday.

Thank you very much for your hints!

MichaIng commented 11 months ago

Could you give me any advice how to implement a variable and so on, since I don't have the foggiest idea ... Anyway I will switch on "4: Daemon + Drift" for some week(s) to test further.

The idea was to implement (respecting) a variable into our scripts, and expose that to dietpi.txt.

In my router is a field in which “0. europe. pool. ntp. org” is entered by default. Unfortunately, this server is - as the saying goes in Internet - also often unreachable. In addition I read, it would be better to use a timeserver as close as possible, which increases accuracy. And also not to use a pool, because they were lame and also built connections (NTP) to RU & UA (according to ntopng), not to mention data protection....

This field is no particular server but a pool already. Those NTP pools are well known, and the URL should redirect your NTP requests to a close actual server (pool member) automatically. You can select the very same pool directly in DietPi, which adds 4 particular entries 0.europe.pool.ntp.org - 3.europe.pool.ntp.org, so at least is not reachable, or answers slow, the next is attempted, or even all 4 concurrently, IIRC. But since your router serves as sort of NTP cache, it is generally preferable compared to having all LAN hosts sync with the NTP pool themselves.

The question remains why DietPi succeeded with the raw network connection check (pinging 9.9.9.9 by default), hence when the router had its Internet connectivity active, but failed with the time sync afterwards. You do have automatic dietpi-update check enabled, i.e. CONFIG_CHECK_DIETPI_UPDATES=1 in /boot/dietpi.txt, right?

pipapoquant commented 11 months ago

The idea was to implement (respecting) a variable into our scripts, and expose that to dietpi.txt. Very good idea. May I suggest to implement it within dietpi-config, because 1) There is the option to activate / switch to "Daemon + Drift", too. 2) As far as I understood dietpi.txt will be used only once on a new installation. Or will it be executed after every new start of diet-pi?

You do have automatic dietpi-update check enabled, i.e. CONFIG_CHECK_DIETPI_UPDATES=1 in /boot/dietpi.txt, right? Yes, I do.

...better switch to "4 : Daemon + Drift". This way, systemd-timesyncd keeps running, and retrying faster if the first time sync fails. This also makes more sense than a "every 15 minutes" setting, since too regular wrapper script and server start and stops may lead to overall higher system load than just leaving the service up. But what could make sense is to implement a variable to change the time sync timeout for hourly/daily mode, and/or increasing it for the first time sync at boot, as this is the most important one.

Could you give me any advice how to implement a variable and so on, since I don't have the foggiest idea ... Anyway I will switch on "4: Daemon + Drift" for some week(s) to test further.

Since I switched to "4: Daemon + Drift" I experienced no errors. Everything seems to work. Great! Thank you!

I would appreciate it if you would still implement this:

... to implement a variable to change the time sync timeout for hourly/daily mode, and/or increasing it for the first time sync at boot, as this is the most important one.

Off topic suggestion:

I might take this opportunity to suggest something else: Perhaps an automatic update option would be convenient for all lazy and "courageous" users: So not only an update/upgrade-notification, but also installation of anything without demand . . . Possibly with the option to undo the last installation, if something should go wrong.

Thank you very much, merry Christmas and a Happy New Year!

MichaIng commented 11 months ago

Some dietpi.txt options are relevant only on 1st boot, especially the ones prefixed with AUTO_. Some others are also more flags for our scripts to know what has been applied before, but do not work by themselves. The time sync mode option however works by just editing in dietpi.txt, since its only our own scripts which are affected by this. The idea of this timeout variable would as well work OOTB, since its as well our own script which waits for currently 60 seconds before stopping the time sync service, if no "Daemon + Drift" mode is enabled. It actually uses the variable MAX_LOOPS_CHECK already, so you can do e.g. MAX_LOOPS_CHECK=300 /boot/dietpi/func/run_ntpd 1 for a 5 minutes timeout. But since the script is called from a cron job, a dietpi.txt setting needs to be parsed from our cron job, then passed like above to the time sync script.

We intentionally do not offer automatic DietPi updates, since we often use this to inform our users about important changes, available optional updates for software options, some other interactive choices by times. Security-wise, the most important thing is to keep APT packages updated, which can be automated with a dedicated setting CONFIG_CHECK_APT_UPDATES=2 in dietpi.txt

You can create your own cron job or service and run

/boot/dietpi/dietpi-update 1

or if it still runs with STDIN attached to a console

G_INTERACTIVE=0 /boot/dietpi/dietpi-update 1

to automate it. But you will miss mentioned info/choices in this case, so I generally do not recommend it.

merry Christmas and a Happy New Year!

Many thanks 🎅 😃. Reminds me to send some greetings via MOTD.

pipapoquant commented 10 months ago

Thank you very much for your explanations. Everything works still well. I've questions concerning the following remarks:

" ... It actually uses the variable MAX_LOOPS_CHECK already, so you can do e.g. MAX_LOOPS_CHECK=300 /boot/dietpi/func/run_ntpd 1 for a 5 minutes timeout. But since the script is called from a cron job, a dietpi.txt setting needs to be parsed from our cron job, then passed like above to the time sync script. ..."

Now I'm standing there like a duck in a thunderstorm without understanding, what I should enter in which line of dietpi.txt and elsewhere.

Could you give me an copy/paste-example of code please?

Where / in which line shall I amend the dietpi.txt?

What variables would you choose if you were me? What makes sense?

Thank you very much indeed!