Pi-Hole crashes every now and then

LuigiTheHunter · June 25, 2019, 7:37pm

Expected Behaviour:

[Not crashing, for more then three days in a row.]

Actual Behaviour:

[Everyday it crashes at different times. Then it just shows "500 Internal Server error"]

Debug Token:

[https://tricorder.pi-hole.net/pxn5vlfhu6]

Here is the log entry where It did stop:

Jun 25 08:18:38 dnsmasq[615]: query[AAAA] 1.debian.pool.ntp.org from 127.0.0.1
Jun 25 08:18:38 dnsmasq[615]: forwarded 1.debian.pool.ntp.org to 1.0.0.1
Jun 25 08:18:38 dnsmasq[615]: reply 1.debian.pool.ntp.org is 51.255.197.148
Jun 25 08:18:38 dnsmasq[615]: reply 1.debian.pool.ntp.org is 5.9.113.140
Jun 25 08:18:38 dnsmasq[615]: reply 1.debian.pool.ntp.org is 31.130.200.24
Jun 25 08:18:38 dnsmasq[615]: reply 1.debian.pool.ntp.org is 37.187.122.11
Jun 25 08:18:38 dnsmasq[615]: reply 1.debian.pool.ntp.org is NODATA-IPv6
Jun 25 20:34:55 dnsmasq[615]: query[A] api.eu.amazonalexa.com.fritz.box from 10.13.37.101
Jun 25 20:34:55 dnsmasq[615]: forwarded api.eu.amazonalexa.com.fritz.box to 1.0.0.1
Jun 25 20:34:55 dnsmasq[615]: forwarded api.eu.amazonalexa.com.fritz.box to 1.1.1.1
Jun 25 20:34:55 dnsmasq[615]: query[A] www.facebook.com.fritz.box from 10.13.37.20
Jun 25 20:34:55 dnsmasq[615]: forwarded www.facebook.com.fritz.box to 1.0.0.1
Jun 25 20:34:55 dnsmasq[615]: query[A] www.facebook.com from 10.13.37.20
Jun 25 20:34:55 dnsmasq[615]: /etc/pihole/gravity.list www.facebook.com is 0.0.0.0
Jun 25 20:34:55 dnsmasq[615]: query[A] clients1.google.com.fritz.box from 10.13.37.20
Jun 25 20:34:55 dnsmasq[615]: forwarded clients1.google.com.fritz.box to 1.0.0.1
Jun 25 20:34:55 dnsmasq[615]: query[A] clients1.google.com from 10.13.37.20
Jun 25 20:34:55 dnsmasq[615]: forwarded clients1.google.com to 1.0.0.1
Jun 25 20:34:55 dnsmasq[615]: reply clients1.google.com is <CNAME>
Jun 25 20:34:55 dnsmasq[615]: reply clients.l.google.com is 172.217.18.110

What I have tried so far is creating a cronjob for restarting the Pi at 4AM everyday but unfortunately this did not work.

It could be that this is SDCard related maybe? Just a thought of mine... But the Pi does work normally though.

Thanks in advance.

Mcat12 · June 28, 2019, 2:12am

Please make a new debug token, as they expire after 48 hours. Is DNS resolution still working regardless of the HTTP errors?

LuigiTheHunter · June 28, 2019, 7:57am

Thanks for the answer
Nope DNS is not working anymore than. Here is the new token:https://tricorder.pi-hole.net/drqs28d9pp

RamSet · June 28, 2019, 4:29pm

The debug log is clean and it does show that the DNS blocking is working.

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] playboysamking.blogspot.ba is 0.0.0.0 via localhost (127.0.0.1)
[✓] playboysamking.blogspot.ba is 0.0.0.0 via Pi-hole (10.13.37.2)
[✓] doubleclick.com is 172.217.18.14 via a remote, public DNS server (8.8.8.8)

When you are experiencing DNS issues, without attempting any repair steps, run

sudo systemctl status --full --no-pager pihole-FTL.service and post the result of that output.

LuigiTheHunter · June 28, 2019, 8:24pm

Thanks, wilco!

Mcat12 · June 29, 2019, 2:10am

I did notice a bad line in /etc/pihole/adlists.list:

https://raw.githubusercontent.com/StevenBlack/hosts/master/data/KADhosts/hosts	s://raw.githubusercontent.com/EnergizedProtection/block/master/extensions/xtreme/formats/domains.txt

LuigiTheHunter · June 30, 2019, 9:11am

It crashed again so I created a new token:
https://tricorder.pi-hole.net/ma1xyhfifh
ma1xyhfifh

Mcat12 · June 30, 2019, 6:53pm

The only issue I see is here, from the FTL log:

[2019-06-30 10:56:59.162 628] WARN: getOverTimeID(1561884900): 185 is too large: 1561773900

This usually means that the device's time was changed, however it is not a fatal error.

It would be useful to get the output that @RamSet requested:

LuigiTheHunter · June 30, 2019, 7:06pm

Thanks for answering, sorry I oversaw your answer here is the requested log:

● pihole-FTL.service - LSB: pihole-FTL daemon
   Loaded: loaded (/etc/init.d/pihole-FTL; generated; vendor preset: enabled)
   Active: active (exited) since Sun 2019-06-30 20:57:32 CEST; 7min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 480 ExecStart=/etc/init.d/pihole-FTL start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/pihole-FTL.service

Jun 30 20:57:28 raspberrypi systemd[1]: Starting LSB: pihole-FTL daemon...
Jun 30 20:57:29 raspberrypi pihole-FTL[480]: Not running
Jun 30 20:57:29 raspberrypi su[575]: Successful su for pihole by root
Jun 30 20:57:29 raspberrypi su[575]: + ??? root:pihole
Jun 30 20:57:29 raspberrypi su[575]: pam_unix(su:session): session opened for user pihole by (uid=0)
Jun 30 20:57:32 raspberrypi pihole-FTL[480]: FTL started!
Jun 30 20:57:32 raspberrypi systemd[1]: Started LSB: pihole-FTL daemon.

@Mcat12

Mcat12 · June 30, 2019, 7:35pm

Please also share the output of this command:

journalctl -u pihole-FTL --full --no-pager

LuigiTheHunter · June 30, 2019, 8:49pm

Sure, there you go:

-- Logs begin at Sun 2019-06-30 20:57:07 CEST, end at Sun 2019-06-30 22:48:52 CEST. --
Jun 30 20:57:28 raspberrypi systemd[1]: Starting LSB: pihole-FTL daemon...
Jun 30 20:57:29 raspberrypi pihole-FTL[480]: Not running
Jun 30 20:57:29 raspberrypi su[575]: Successful su for pihole by root
Jun 30 20:57:29 raspberrypi su[575]: + ??? root:pihole
Jun 30 20:57:29 raspberrypi su[575]: pam_unix(su:session): session opened for user pihole by (uid=0)
Jun 30 20:57:32 raspberrypi pihole-FTL[480]: FTL started!
Jun 30 20:57:32 raspberrypi systemd[1]: Started LSB: pihole-FTL daemon.

Mcat12 · June 30, 2019, 9:08pm

I don't see any further issues in those logs, is it working?

LuigiTheHunter · June 30, 2019, 9:48pm

Until now yes. Sometimes it takes several days to stop working again. I will look a bit closer on this and will send all logs again if it occurs again. Thanks alot!!

LuigiTheHunter · July 7, 2019, 10:07am

It happend again, I made a log again https://tricorder.pi-hole.net/rdp8dcsjrt

I don't if pi-hole is causing this, after I ran in this problem again today, I noticed that I couldn't even connect to my PI via SSH "connection reset-by-peer". And I had to unplug it and plug it in again.

DL6ER · July 7, 2019, 10:27am

My guess is a broken/insufficient power supply. This can cause unstable operation and crashes in unforeseeable intervals, e.g., under heavier load when it decides to update the package lists or some other background job is triggered.

Can you check if the situation improves with a different (more beefy) power supply?

LuigiTheHunter · July 7, 2019, 11:22am

Sure I can check. But I recently already changed from one p-supply to another (new one should be better). I will check this, and come back 2 you thanks.

system · July 28, 2019, 11:22am

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.