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:
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 "
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:
@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?
That was the initial idea yeah ... if you were to check the other EXT4 partition on another PC at same time anyway.
Dont need to to do that now.
/boot partition/mount is only invoked at boot time so after the system comes up, that
/boot partition is not involved anymore.
If you want to check anyway (without the desktop PC), make sure no processes have files open on that
pi@ph5:~ $ sudo lsof /boot/ pi@ph5:~ $
Unmount the filesystem:
pi@ph5:~ $ sudo umount /boot pi@ph5:~ $
fsck (with auto repair argument) on the partition:
pi@ph5:~ $ sudo fsck -y /dev/mmcblk0p1 fsck from util-linux 2.33.1 fsck.fat 4.1 (2017-01-24) /dev/mmcblk0p1: 241 files, 109198/516190 clusters
And mount it again:
pi@ph5:~ $ sudo mount -a pi@ph5:~ $
pi@ph5:~ $ findmnt /boot TARGET SOURCE FSTYPE OPTIONS /boot /dev/mmcblk0p1 vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro
When the timeouts occure, are you still able to ping and SSH into the Pi ?
If so, it could be the configured upstream DNS servers causing troubles somehow.
Try do below two when have problems again and post results here:
nslookup pi-hole.net 184.108.40.206
nslookup pi-hole.net 220.127.116.11
And when have another PC running Windows, Linux or MacOS, run above same two commands on them in a command prompt too.
@deHakkelaar after pointing the router back to the pihole this afternoon (~2:00 pm), internet cut out at around 5.
Results from your queries are below:
From the pi-hole
The Windows machine was also unable to connect to anything.
You seem to have intermittent problems with your Internet connection.
This is not really Pi-hole related.
Run below one on Pi-hole when everything is working and when not working (timeouts) to compare:
traceroute -n 18.104.22.168
Same for the Windows machine:
tracert -d 22.214.171.124
And depending results, report an issue at your ISP.
Thanks everyone! I appreciate all the effort you've all put into this!
Wat was solution ?