I have a Pi-Hole on my network to monitor and block DNS requests. My Pi running OSMC is making around 2,500 requests every 24 hours to debian.pool.ntp.org. They are not being blocked. I understand this is for system time but the local timezone and time are set and showing correctly. This seems a bit extreme to me. Is there something wrong?
That seems like 2 request per minute. The number of sync request of NTP is based on the stability of the local clock.
I’ve just read that and it doesn’t tell me how I can improve the stability. It’s just a standard Pi3b+. Maybe I should just block it and see what happen?
Well what will happen I can tell you. Your clock over time will be getting off.
While I just checked on my OSMC/Pi and I have not got a single NTP request within 3 minutes.
Check what ntpq -p gives you
I don’t know if it’s related to this problem but there seems to be a bug in the Pi2/3/3+ build image (haven’t checked the Vero4K) that has /var/lib/ntp owned by user systemd-bus-proxy, rather than by user ntp:
osmc@osmc:~$ ls -la /var/lib/ntp
total 8
drwxr-xr-x 2 systemd-bus-proxy ntp 4096 Feb 15 2018 .
drwxr-xr-x 25 root root 4096 Jul 21 19:27 ..
As you can see, user ntp only has group read access to this directory and this prevents the ntp service from creating a file ntp.drift.
It can be fixed with the command sudo chown ntp:ntp /var/lib/ntp
@sam_nazarko the error is present in the filesystem.tar.xz file. The uid for user ntp is 105, not 104.
Good find, that is most likely the cause. Actually mi Pi3 install is quite old and the owner is right. Let me give it a try what happens if I change the owner
Well obviously changing the group hinders the ntp.drift file to be created. But at least my short test didn’t show any massive requests to the NTP servers and the clock still was corrected. But it still might be part of the issue
that can happen if the pi doesnt have a good connection using pihole myself and if your internet connection is down or intermittently not working as intended alot of request to ntp will fly out… not a osmc problem per say its more or less a network problem.
simple way to reproduce this problem is simply unhooking your wan connection 
and watch the ntp request fly up instantly
Both running the same version of NTP? I can’t think of anything that’d touch this file and they’re deployed the same way on both images
One thing I want to make sure is clear…is your Pi making 2500 DNS requests every 24 hours, or is it making 2500 attempts to connect via NTP?
The first means there is an issue with DNS cache, either on the Pi or your local DNS server, since the TTL on that record is 1 hour. The second would likely mean a problem with NTP, as other posts here have pointed out.
Sorry but I’m not sure which one. My ability to interpret the log is limited!
Running:
ntpq -p
gives:
remote refid st t when poll reach delay offset jitter 0.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.001 1.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.001 2.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.001 3.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.001 +x.ns.gin.ntt.ne 249.224.99.213 2 u 522 1024 377 14.748 2.275 8.402 -y.ns.gin.ntt.ne 249.224.99.213 2 u 605 1024 377 23.118 4.424 9.760 +pve01.as24220.n 180.150.12.46 2 u 616 1024 377 23.687 0.104 1.858 +cachens2.onqnet 3.0.139.10 3 u 597 1024 377 29.228 0.881 3.377 *cachens1.onqnet 3.108.15.84 2 u 290 1024 377 33.968 3.888 11.617
Then I ran:
~$ ls -la /var/lib/ntp
total 12
drwxr-xr-x 2 ntp ntp 4096 Aug 1 18:19 .
drwxr-xr-x 15 root root 4096 Apr 30 2018 ..
-rw-r--r-- 1 ntp ntp 6 Aug 1 18:19 ntp.drift
I’ll leave it a day and see what happens.
A connection to port 53 is DNS, while NTP is port 123.
Based on the results of ntpq -p, if your PiHole log is reporting connections to debian.pool.ntp.org, then it’s almost certainly a DNS issue.
NTP seems to be connecting fine (the last 8 attempts to every server have succeeded based on the reach values) and is only doing so every 17 minutes (1024 seconds between polls).
It could be a weird bug in ntpd that doesn’t respect the TTL of the DNS record when the type of server is really a pool.
or as i said it could be a bad connection when pihole doesnt connect proper, it happens trust me…
@transfers does it happen every day or just intermittently ?
and in pihole did it forward every request or did it comeback as nodata ?
I should probably learn more about the Pi-hole. I am prone to drop-outs here so will investigate that.