FLTDNS Server not responding every minute

[DocMAX]

I have the problem that Pihole’s DNS server is not responting for a few seconds every minute.
I am running Pihole with debug switch and i can’t see anything suspicus.

What can i do to?

[nosugref42]

Not a lot of information to work with at this point.

Perhaps start by describing your environment, things you have tried, or changed, and providing a debug token for the development team. Just the generated token, and not the actual log.

[DocMAX]

Here is is the token: https://tricorder.pi-hole.net/0Y4qJPDf/

I created a small script on my client. Tested on other clients, too.

Mo 17. Nov 13:51:58 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:51:59 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:02 CET 2025: UDP Port 53 on 192.168.1.100 not responding
Mo 17. Nov 13:52:06 CET 2025: UDP Port 53 on 192.168.1.100 not responding
Mo 17. Nov 13:52:08 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:09 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:10 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:11 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:12 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:13 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:14 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:15 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:16 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:17 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:19 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:20 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:21 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:22 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:23 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:24 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:25 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:26 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:27 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:28 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:29 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:30 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:31 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:32 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:33 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:34 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:35 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:36 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:37 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:38 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:39 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:40 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:41 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:42 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:43 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:44 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:45 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:46 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:47 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:48 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:49 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:50 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:51 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:52 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:53 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:54 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:55 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:56 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:57 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:58 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:52:59 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:53:02 CET 2025: UDP Port 53 on 192.168.1.100 not responding
Mo 17. Nov 13:53:05 CET 2025: UDP Port 53 on 192.168.1.100 not responding
Mo 17. Nov 13:53:08 CET 2025: UDP Port 53 on 192.168.1.100 not responding
Mo 17. Nov 13:53:09 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:53:10 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:53:11 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:53:12 CET 2025: UDP Port 53 on 192.168.1.100 responding
Mo 17. Nov 13:53:13 CET 2025: UDP Port 53 on 192.168.1.100 responding

I disabled all my Minute-Cronjobs. Did not fix the problem.
Also i can see packets incomming with tcpdump during the non-responding timeframe.

Edit: I replaced FLTDNS with regular dnsmasq package from Debian 12. The result was no problems. So the problem lies within Pihole DNS. Is it possible to fallback to the systems dnsmasq?

Here is a strace. The time gap is the non-response:

16:22:59.976619 getpid() = 2292844
16:22:59.976815 gettid() = 2292844
16:22:59.976977 clock_gettime(CLOCK_REALTIME, {tv_sec=1763392979, tv_nsec=977082311}) = 0
16:22:59.977188 poll([{fd=3, events=POLLIN}, {fd=20, events=POLLIN}, {fd=21, events=POLLIN}, {fd=22, events=POLLIN}, {fd=23, events=POLLIN}, {fd=24, events=POLLIN}, {fd=25, events=POLLIN}, {fd=37, events=POLLIN}], 8, -1) = 1 ([{fd=37, revents=POLLIN}])
16:22:59.977467 clock_gettime(CLOCK_REALTIME, {tv_sec=1763392979, tv_nsec=977533695}) = 0
16:22:59.977624 recvfrom(37, "\322\312\201\203\0\1\0\0\0\0\0\1\fdesktop-htpc\3lan\0\0\1"..., 2267, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.1.1")}, [28 => 16]) = 45
16:22:59.977815 close(37) = 0
16:22:59.978080 clock_gettime(CLOCK_REALTIME, {tv_sec=1763392979, tv_nsec=978165898}) = 0
16:22:59.978349 clock_gettime(CLOCK_REALTIME, {tv_sec=1763392979, tv_nsec=978492335}) = 0
16:22:59.978607 getpid() = 2292844
16:22:59.978749 gettid() = 2292844
16:22:59.978889 sendmsg(20, {msg_name={sa_family=AF_INET, sin_port=htons(50041), sin_addr=inet_addr("192.168.1.196")}, msg_namelen=16, msg_iov=[{iov_base="\331B\201\203\0\1\0\0\0\0\0\1\fdesktop-htpc\3lan\0\0\1"..., iov_len=45}], msg_iovlen=1, msg_control=[{cmsg_len=28, cmsg
16:22:59.979155 poll([{fd=3, events=POLLIN}, {fd=20, events=POLLIN}, {fd=21, events=POLLIN}, {fd=22, events=POLLIN}, {fd=23, events=POLLIN}, {fd=24, events=POLLIN}, {fd=25, events=POLLIN}], 7, -1) = 1 ([{fd=20, revents=POLLIN}])
16:23:00.009494 clock_gettime(CLOCK_REALTIME, {tv_sec=1763392980, tv_nsec=9587814}) = 0
16:23:00.009701 recvmsg(20, {msg_name={sa_family=AF_INET, sin_port=htons(38276), sin_addr=inet_addr("192.168.1.215")}, msg_namelen=28 => 16, msg_iov=[{iov_base="\236\26\1 \0\1\0\0\0\0\0\1\7example\3com\0\0\1\0\1\0\0)"..., iov_len=1232}], msg_iovlen=1, msg_control=[{cmsg_len
16:23:00.009958 ioctl(20, SIOCGIFNAME, {ifr_ifindex=2, ifr_name="eth0"}) = 0
16:23:00.010154 clock_gettime(CLOCK_REALTIME, {tv_sec=1763392980, tv_nsec=10220506}) = 0
16:23:00.010348 clock_gettime(CLOCK_REALTIME, {tv_sec=1763392980, tv_nsec=10410683}) = 0
16:23:00.010514 getpid() = 2292844
16:23:00.010655 gettid() = 2292844
16:23:00.010811 clock_gettime(CLOCK_REALTIME, {tv_sec=1763392980, tv_nsec=10870867}) = 0
16:23:00.010966 getpid() = 2292844
16:23:00.011102 gettid() = 2292844
16:23:00.011241 clock_gettime(CLOCK_REALTIME, {tv_sec=1763392980, tv_nsec=11318899}) = 0
16:23:00.011410 getpid() = 2292844
16:23:00.011547 gettid() = 2292844
16:23:00.011689 clock_gettime(CLOCK_REALTIME, {tv_sec=1763392980, tv_nsec=11746397}) = 0
16:23:00.011834 getpid() = 2292844
16:23:00.011971 gettid() = 2292844
16:23:00.012107 clock_gettime(CLOCK_REALTIME, {tv_sec=1763392980, tv_nsec=12166003}) = 0
16:23:00.012256 getpid() = 2292844
16:23:00.012480 gettid() = 2292844
16:23:00.012695 clock_gettime(CLOCK_REALTIME, {tv_sec=1763392980, tv_nsec=12763495}) = 0
16:23:00.012865 getpid() = 2292844
16:23:00.013836 gettid() = 2292844
16:23:00.014023 clock_gettime(CLOCK_REALTIME, {tv_sec=1763392980, tv_nsec=14186929}) = 0
16:23:00.014361 getpid() = 2292844
16:23:00.014663 gettid() = 2292844
16:23:00.014883 clock_gettime(CLOCK_REALTIME, {tv_sec=1763392980, tv_nsec=14950503}) = 0
16:23:00.015054 getpid() = 2292844
16:23:00.015320 gettid() = 2292844
16:23:00.015747 clock_gettime(CLOCK_REALTIME, {tv_sec=1763392980, tv_nsec=15856064}) = 0
16:23:00.016030 getpid() = 2292844
16:23:00.016301 gettid() = 2292844
16:23:00.016681 clock_gettime(CLOCK_REALTIME, {tv_sec=1763392980, tv_nsec=16801505}) = 0
16:23:00.016926 getpid() = 2292844
16:23:00.017138 gettid() = 2292844
16:23:00.017503 clock_gettime(CLOCK_REALTIME, {tv_sec=1763392980, tv_nsec=17610126}) = 0
16:23:00.017767 getpid() = 2292844
16:23:00.018460 gettid() = 2292844
16:23:00.019208 clock_gettime(CLOCK_REALTIME, {tv_sec=1763392980, tv_nsec=19356646}) = 0
16:23:00.019499 getpid() = 2292844
16:23:00.019709 gettid() = 2292844
16:23:00.019925 clock_gettime(CLOCK_REALTIME, {tv_sec=1763392980, tv_nsec=20016157}) = 0
16:23:00.020166 getpid() = 2292844
16:23:00.020786 gettid() = 2292844
16:23:00.021017 sendmsg(20, {msg_name={sa_family=AF_INET, sin_port=htons(38276), sin_addr=inet_addr("192.168.1.215")}, msg_namelen=16, msg_iov=[{iov_base="\236\26\201\200\0\1\0\6\0\0\0\1\7example\3com\0\0\1\0\1\300\f\0"..., iov_len=136}], msg_iovlen=1, msg_control=[{cmsg_le
16:23:00.021550 poll([{fd=3, events=POLLIN}, {fd=20, events=POLLIN}, {fd=21, events=POLLIN}, {fd=22, events=POLLIN}, {fd=23, events=POLLIN}, {fd=24, events=POLLIN}, {fd=25, events=POLLIN}], 7, -1) = 1 ([{fd=20, revents=POLLIN}])
16:23:00.133598 clock_gettime(CLOCK_REALTIME, {tv_sec=1763392980, tv_nsec=133681564}) = 0
16:23:00.133917 recvmsg(20, {msg_name={sa_family=AF_INET, sin_port=htons(39308), sin_addr=inet_addr("192.168.1.215")}, msg_namelen=28 => 16, msg_iov=[{iov_base="\351b\1\0\0\1\0\0\0\0\0\1\fdesktop-game\3lan\0\0\34"..., iov_len=1232}], msg_iovlen=1, msg_control=[{cmsg_len=28,
16:23:00.134172 ioctl(20, SIOCGIFNAME, {ifr_ifindex=2, ifr_name="eth0"}) = 0
16:23:00.134361 clock_gettime(CLOCK_REALTIME, {tv_sec=1763392980, tv_nsec=134422300}) = 0
16:23:00.134527 clock_gettime(CLOCK_REALTIME, {tv_sec=1763392980, tv_nsec=134587963}) = 0
16:23:00.134702 futex(0x745962b44004, FUTEX_WAIT, 2149776569, NULL) = 0
16:23:28.865774 getpid() = 2292844
16:23:28.865891 gettid() = 2292844
16:23:28.866002 futex(0x745962b44004, FUTEX_WAKE, 1) = 1
16:23:28.866128 socket(AF_INET, SOCK_DGRAM, IPPROTO_IP) = 40
16:23:28.866249 sendto(40, "\34=\1\0\0\1\0\0\0\0\0\1\fdesktop-game\3lan\0\0\34"..., 45, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.1.1")}, 16) = 45
16:23:28.866503 clock_gettime(CLOCK_REALTIME, {tv_sec=1763393008, tv_nsec=866565338}) = 0
16:23:28.866655 getpid() = 2292844
16:23:28.866754 gettid() = 2292844

Next Edit:
Every minute i can see a 100% CPU usage on one core!

AI proposal:

Holding the SHM lock during disk/db operations is causing the block/high CPU. Split your logic so only in-memory ops are protected. Move disk/db work OUTSIDE the lock.