It looks like CF is off, and always has been. I am using the pihole as the DHCP server, so maybe I configured that wrong in some way?
@Bucking_Horn does that make any sense?
What's your Pi-hole using as upstream DNS servers?
Cloudflare. Should I be selecting something else?
No, your problem seems related to local DNS resolution, as your nslookup fails on resolving pi.hole.
Like said before, timeouts could have indicated a DNS loop.
You don't have CF enabled, so the only possible way you could've closed a loop would have been if your Pi-hole used your router as upstream, and your router uses Pi-hole.
Timeouts may also occur with incorrect routing, e.g. when accessing your Pi-hole across VLANs or via a VPN. Would you be using any of these?
No VLANs or VPNs...could it be the cache size?
@Bucking_Horn do I just bail? Do we just say that this is not functional for some unknown reason?
Did you check whether your router would interfere?
Also, did you consider deHakkelaar's earlier suggestions?
If so, what was the outcome?
@Bucking_Horn of @deHakkelaar 's suggestions, the only one it could possible be is running out of memory. I'm using the power adapter that came with the Canakit starter pack, which should mean no under voltage. The Pihole doesn't need a reboot, I just have to tell the router to use default dns for a few minutes, then point it back again. Finally, the Pihole is connected by ethernet.
How would I know if it's running out of memory?
I think deHakkelaar has provided that information in his links.
In the meantime, let's recheck your earlier results.
Run from a client, what's the output of:
nslookup flurry.com
Also, please post a new debug token.
Below one allows you to scroll through the kernel ring buffer/logs while at same time highlighting any "oom" messages:
dmesg -T | less -p oom
Typically you'll see something like below when the oom-killer is killing some process:
[Thu Sep 17 10:58:29 2020] nmbd invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
[Thu Sep 17 10:58:29 2020] CPU: 1 PID: 2154 Comm: nmbd Tainted: G C 5.4.27+ #1
[Thu Sep 17 10:58:29 2020] Hardware name: BCM2835
[Thu Sep 17 10:58:29 2020] Backtrace:
[Thu Sep 17 10:58:29 2020] [<c020e09c>] (dump_backtrace) from [<c020e398>] (show_stack+0x20/0x24)
[Thu Sep 17 10:58:29 2020] r6:c12a6538 r5:c12a6538 r4:00000000 r3:1771de1a
[Thu Sep 17 10:58:29 2020] [<c020e378>] (show_stack) from [<c0b2e348>] (dump_stack+0xd8/0x11c)
[Thu Sep 17 10:58:29 2020] [<c0b2e270>] (dump_stack) from [<c0354760>] (dump_header+0x68/0x21c)
[Thu Sep 17 10:58:29 2020] r8:c12a8940 r7:c0df284c r6:e2269080 r5:cf07eac0 r4:e20b1d40 r3:1771de1a
[Thu Sep 17 10:58:29 2020] [<c03546f8>] (dump_header) from [<c0354e24>] (oom_kill_process+0x15c/0x1a4)
[Thu Sep 17 10:58:29 2020] r9:c12056d0 r8:c12a8940 r7:c0df284c r6:e20b1d40 r5:cf07f02c r4:cf07eac0
[Thu Sep 17 10:58:29 2020] [<c0354cc8>] (oom_kill_process) from [<c0355a18>] (out_of_memory+0x120/0x348)
And I wouldnt rule out the power adapter or cable just bc it came in a kit.
The power adapter or cable could be DOA/DFS or just a cheap one not able to do the job.
(Dead On Arrival / Defect From Stock)
That same kernel ring buffer can be checked for "under-voltage" messages:
dmesg -T | grep -i voltage
Or checking the logs stored on the SD card that go longer back (the kernel ring buffer stored in RAM gets wiped on reboot):
zgrep -ni voltage /var/log/syslog.*
And I wouldnt rule out filesystem errors caused by power outage or insufficient or unstable power:
1 Like
@deHakkelaar The voltage checks did not return anything, and I didn't see anything like what you posted for the oom killer, although I noticed that when it cut out this morning the dashboard showed the attached pattern of activity.
.
Is there any way to check for corrupted filesystem while the card is still in the rpi? If not, should I just nuke the card and start fresh?
Check answer below:
But not sure if any results gets logged with above.
Better connect a display to the Pi to see boot sequence.
That screenshot you posted doesnt show the vertical Y axes making it impossible to see how many queries.
Did you check who made all those queries via the web GUI or checking the logs with below ?
less -p 'Oct 8 02:00:00' /var/log/pihole.log
Above one makes me suspect you have configured a DNS loop somewhere.
What upstream DNS server(s) is/are configure on Pi-hole ?
sudo grep server= -R /etc/dnsmasq.*
And what DNS server(s) is/are configured on the router in the WAN/Internet section ?
@deHakkelaar Answers below:
The rpi isn't showing any downtime, do you think I still need to adjust the boot directory?
As to who made the queries: The log doesn't seem to go that far back, but generally my phone is the biggest producer of queries.
Upstream DNS servers:
When I run the code you presented, the outcome is below:
The routers is configured as follows (this is the address for the pihole):
The query log shown on the dashboard does not go back more than 24 hours, but the long-term data tab on the browser will allow you to see all the queries made for the past 365 days (or when Pi-hole was installed, whichever is shorter).
When I tried to view this month's entries, @jfb, I got this error:
If you have inadequate PHP memory, you can increase the memory allocated to PHP:
@jfb @deHakkelaar ok, having now upped my php memory to 1350 M, it looks like the biggest query creator on Oct. 8 was my desktop (61232), followed by my laptop (57153), my wife's phone (49344), my smart display (45283), my daughter's smart speaker (43106), my smart speakers (42927), office speaker (35395), my tablet (34971), the bedroom smart display (27112), and my phone (23733).
What do yo mean by "adjust" ?
My instructions were to check the FAT32 /boot partition with fsck for errors and repair if find any:
pi@noads:~ $ findmnt /boot
TARGET SOURCE FSTYPE OPTIONS
/boot /dev/mmcblk0p1 vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mix
Before, it was your router at 192.168.1.1 making the most queries:
Has anything changed in that respect ?
Do you still experience "Internet Disconnecting After a Few Hours" ?
@deHakkelaar, I'm sorry, you're right. I did change it after I realized that it was easier to see activity if the pihole was providing ip addresses, so I disabled DHCP on the router and enabled it on the pihole.
However, I continue to get the timeout.
To check the /boot partition, I need to remove SD card and plug it into my desktop?