Lost Connection to API [again]

Help
1

Please follow the below template, it will help us to help you!

Expected Behavior:

PiHole works excellently

Actual Behavior:

"Lost Connection to API"

Debug Token:

"There was an error uploading your debug log." [Looks like lots of errors shown in the output.]

image
image652×577 45.9 KB

This is a follow-up to my previous post of about October 19th which is now closed.

Noticing the network was running slow again I checked and found "Lost Connection to API" - same situation as last time.

Here's the end of the file as previously requested by @DL6ER:

image

DNSSEC is on. I'm going to leave the PiHole as-is for the remainder of the day [holiday here today] if further diagnostics are needed while it is in this state but will need to restart it for work tomorrow.

TU!

2

This will temporarily reset the nameserver on the Pi to bypass Pi-Hole DNS.

sudo nano /etc/resolv.conf

edit nameserver 127.0.0.1 to nameserver 9.9.9.9 or your preferred third party DNS service, save and exit

Run pihole -d and upload the debug log

3

Hi @jfb. Thank you. The debug token is cuexet0uiu .

4

Hi. I wonder if you or @DL6ER may have had an opportunity to look at the information represented by the token?

5

Thanks for the reminder before the debug token expired.

I checked your log and see that pihole-FTL was not listening on its ports. I cannot say what happened as both, /var/log/pihole.log and /var/log/pihole-FTL.log are empty in your upload.

Looking at the content of /dev/shmem (also visible in the screenshot you provided before), it seems like your Pi-hole has not seen many(or any) new queries after Nov 24, 03:08. This was roughly four days before you opened your ticket here. Does that match?

Unfortunately, we cannot do much so long after a crash (or whatever happened) as the logs will all have been rotated out of sight by now. Does it work normally when you

sudo service pihole-FTL restart

? If so, simply continue to use your Pi-hole. If it shows again issues, please make sure to back-up the two mentioned log files soon enough (usually one has about 3-4 days time because the rotated logs are not immediately removed by first renamed to .log.1, .log.2, etc.)

6

Hi Thanks very much for your response. sudo service pihole-FTL restart was successful.

My guess is that the timing does match, as you say. We don't know exactly when it failed as on our network we have access to two PiHoles -- one on the local L2 segment and one at a different location -- L3 and accessible via "nailed up" VPN. So, although the primary failed, the secondary kept working. So, the effect was just slower DNS resolution -- but not dramatically slower such that we'd necessarily notice it.

I'll turn off DNSSEC and see if that makes a difference vis-a-vis stability. And, I'll try to follow your suggestions if it crashes again.

TU!

7

Hi @DL6ER. Well, it occurred again just this evening. I followed the instructions from @jfb and reset the DNS to 9.9.9.9. Then ran pihole -d. The debug token is s0ibn3ggih.

No idea how to back up the logs as you suggested in your most recent post but I am hopeful that I caught this soon enough the information you need is not lost.

image
image1240×144 16.9 KB

Rick

8

The debug log appears to have the details of the crash. @DL6ER will be able to sort this.

9

What you guyz do amazes me.

10

Di you re-enable DNSSEC? Looking at your debug log, it shows the exact same crash as discussed here:

I'm sorry that this is still happening, however, there isn't much we can do about it right now as it is an issue with the embedded dnsmasq.

11

Hi. I appreciate your response. Yes, DNSSEC was active when the crash occurred. I have three PiHoles running at different locations. Two of the three work fine with DNSSEC; the one discussed here does not. Curious!

OK ... I'll just not use DNSSEC at this location. Thanks for looking at the issue!

12

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