I noticed that Pihole 6 has a built in NTP server. I had installed chrony on my pihole server, but I am not doing anything out of the ordinary with it, so I am wondering whether I would benefit from more simplicity by ditching chrony in favour of what is built into Pihole.
Where can I find more info about the ntp server so I can decide? I couldn't find any mention of it in the Pihole docs.
I think the best place to understand which options Pi-hole NTP server offers is to read the web interface Settings > All settings page.
There is a "Network Time Sync" tab containing all settings and the correspondent help text.
The same text can be found in /etc/pihole/pihole.toml file.
Pi-hole's NTP feature focuses on syncing time with a given NTP server, and serving the system's time to clients via unicasts.
That would fit most home network time requirements, where it's enough to have clients refer to a time frame with an accuracy of only a few miliseconds, but may not meet advanced requirements.
In particular, Pi-hole's NTP feature e.g. doesn't manage a set of upstream NTP servers to select the most reliable time source from, it doesn't discipline the system's clocks, it doesn't automatically account for local clock drift, it doesn't support broadcast, multicast and manycast communications, neither for clients nor servers, and it cannot communicate with reference clocks on the same machine directly (as e.g. ntpd would support).
If you'd have to rely on any of those, you probably should opt for a more full-featured NTP server like chrony or ntpd.
If not, using Pi-hole's NTP feature is perfectly viable.
Thanks - that is helpful. What you wrote would be really helpful in the documentation for pihole.
As ntp.sync.active is set to enabled by default, isn't there a conflict with a running systemd-timesyncd.service (or chrony)?
My assumption would have been that if systemd-timesyncd.service is active, ntp.sync.active is set to disabled by default.
That's correct. If there is an running NTP server already, they would conflict about port 123.
However, my understanding is that systemd-timesyncd.service is a NTP client, not a server.
No, ntp.sync.active wouldn't create conflicts with other NTP clients like systemd-timesyncd, or chrony in its default client only mode, as each would send out its own syncs to a remote port 123.
But Pi-hole also comes with an NTP server that it tries to enable, and that may conflict over listening on port 123 with other NTP servers like a chrony with its NTP server enabled.
To prevent conflicts, Pi-hole's NTP service starts late and checks for other NTP servers, and if those were detected, Pi-hole's NTP server wouldn't start.
The description for ntp.sync.active is
Should FTL try to synchronize the system time with an upstream NTP server?
My main concern here is that there are two components that synchronize the system time. There should only be one.
This thread helped me to understand and fix my NTP problem.
I have long had chrony running on my pihole. Normally after a restart it would take about 2-3 hours to reach a steady state where all the upstream servers were being polled every 1024 seconds (or longer) and nothing much ever changed.
After upgrading pihole from 5.x to 6.x, chrony still had not reached a steady state after a week. It looks like the (S)NTP service in FTL was making step changes to the system clock which confused chrony.
I found the Network Time Sync settings page in pihole and unchecked all the checkboxes. After an hour or so, chrony finally settled down to the normal steady state again.
Perhaps either pihole -up or FTL could check to see if there is already an ntpd or chronyd service enabled in the system, and then disable the one in FTL.
This was exactly my assumption above, also with systemd-timesyncd. Thanks for the confirmation.
Yeah, the clock disciplining algorithms of chrony, ntp and ntpsec don't take too well to those extra time syncs.
I've submitted a PR that covers new installs of pihole, to disable
It's much less of an issue with Systemd-timesyncd, as it is only an SNTP service and does not discipline the clock.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.