FTL issues: Connection refused. Is FTL running?

Help
1

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

Expected Behaviour:

Queries and Graphs in Admin area should return results. Pihole seems to be working normally.

Actual Behaviour:

Graphs just showing spinning wheel forever. Queries returns "An error occured while loading the data: Connection refused. Is FTL running?"

Debug Token:

sagt77s7xz

I've tried everything on this page FTL issues, Connection refused. Is FTL running?. My output is the same as on that page. Including running echo ">stats" | nc -v pi.hole 4711 gives nc: connect to pi.hole port 4711 (tcp) failed: Connection refused

Running pihole -c shows:

  Hostname: raspberrypi        (Raspberry Pi Zero W)
    Uptime: 00:45:59
 Task Load: 1.20 1.22 1.26     (Active: 4 of 41 tasks)
 CPU usage: 114%               (1 GHz @ 324k)
 RAM usage: 15%                (Used: 63 MB of 434 MB)
 HDD usage: 82%                (Used: 5 GB of 6 GB)
  LAN addr: 192.168.1.19       (Gateway: 192.168.1.1)
   Pi-hole: Active             (Blocking: 0 sites)
 Ads Today: 0%                 (Total: 0 of 0)
Local Qrys: 0%                 (4 DNS servers)
   Blocked: FTL offline
Top Advert:
Top Domain:
Top Client:

This is a freshly installed version of pi-hole in a new Raspberry Pi Zero. Everything was working fine today. Then I ran apt-get update && apt-get upgrade. Everything continued to run for another hour or two. After dinner I went to login to the dashboard, and it had stopped functioning as expected. I'd prefer not to reinstall pi-hole, and instead figure out why this happened, if possible.

Edit: Forgot to add that I also ran pihole -r and repair. Still no success.

2

As always... I find a solution shortly after posting. This issue appears to boil down to an error in one of the DNS files. I had added this file:

/etc/dnsmasq.d/02-lan.conf

which includes the single line:

addn-hosts=/etc/pihole/lan.list

The file at /etc/pihole/lan.list seems to have extra text at the end of one line, which cause FTL to do something wrong. Once the lan.list file was updated, dnsmasq restart, and pihole-FTL restarted, all returned to normal.

I was able to re-introduce similar errors which caused FTL to go back offline, and removing those errors, resolved the problem.

Hopefully this solution will be of help to others.

3

So... wake up this morning and FTL is not responding. Looking at the Pi it would appear FTL is actually running, just not responding:

top

26283 pihole    20   0   16880  15420   2580 R 76.0  3.5  23:10.68 pihole-FTL

ps ax | grep FTL

26283 ?        R     24:45 /usr/bin/pihole-FTL

strace -p 26283

stat64("/var/log/pihole.log", {st_mode=S_IFREG|0644, st_size=84903806, ...}) = 0
gettimeofday({tv_sec=1521033048, tv_usec=91992}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3503, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3503, ...}) = 0
gettimeofday({tv_sec=1521033048, tv_usec=94540}, NULL) = 0
gettimeofday({tv_sec=1521033048, tv_usec=94815}, NULL) = 0
gettimeofday({tv_sec=1521033048, tv_usec=127644}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3503, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3503, ...}) = 0

ls -lah /var/log/pihole.log

-rw-r--r-- 1 dnsmasq root 81M Mar 14 09:11 /var/log/pihole.log

Not sure what a normal pihole.log size should be but 81M seems large, especially considering this was from midnight until now (9hours). Why so big? Taking a look I see areas of time where there are thousands of this (about 200+ every second):

Mar 14 01:59:55 dnsmasq[22238]: 11876 192.168.1.1/14562 query[A] time.nist.gov from 192.168.1.1
Mar 14 01:59:55 dnsmasq[22238]: 11876 192.168.1.1/14562 forwarded time.nist.gov to 192.168.1.1
Mar 14 01:59:55 dnsmasq[22238]: 11877 192.168.1.1/5403 query[A] time.nist.gov from 192.168.1.1

And tons of this

Mar 14 01:59:57 dnsmasq[22238]: 11909 192.168.1.1/27554 reply pool.ntp.org is 129.6.15.30
Mar 14 01:59:57 dnsmasq[22238]: 11909 192.168.1.1/27554 reply pool.ntp.org is 45.56.118.161
Mar 14 01:59:57 dnsmasq[22238]: 11908 192.168.1.1/45535 reply pool.ntp.org is 192.52.167.172
Mar 14 01:59:57 dnsmasq[22238]: 11908 192.168.1.1/45535 reply pool.ntp.org is 184.105.182.7

There are also thousands of queries per minute that appear to show my machine checking email. But checking email 200+ times per second is highly unlikely at 2am.

I'm wondering what the chances are that Pi-hole is messing up the logging?

If I blank out pihole.log and restart FTL, everything goes back to normal and FTL is now functioning properly. A few oddities in the Top Domains list:

time.nist.gov 26807
textsecure-service-ca.whispersystems.org 16148
secure20.sync.com 13733dns.msftncsi.com 15547 (this one is fixed on the router as of last night)
4

About those loggings, if you setup your network like described in below link, you wont see those NTP time sync queries coming from (probably?) your router 192.168.1.1 no more:

And about size of the pihole.log file, yes its exceptionally big compared to mine which is only 2.5MB.
But that is to be expected if your router queries Pi-hole that many times a second probably to sync its clock via the NTP protocol.
I dont know what limitations are concerning log size and pihole-FTL.

5

Currently setup using the first method from the link you supplied. Didn't seem to help limit the NTP sync. :frowning:

Edit: My WAN DNS is also point to the pi IP. If I set WAN DNS to external (like 8.8.8.8) then the pi-hole is ignored entirely. Not sure sure this would be.

6

As you might have noticed, that FAQ link doesnt mention altering WAN DNS for the router so best to default that setting again.

7

The reason I altered it, was that leaving the default of 8.8.8.8 and 8.8.4.4 resulted no traffic going to the pi-hole. This morning I put it back to 8.8.8.8 and 8.8.4.4, and again, pi-hole is ignored.

8

You have a router/modem provided by your ISP thats got Google's DNS servers configured for upstream WAN DNS resolution ?
Most ISP's have got their own DNS servers that they push to the router/modem.

I dont understand exactly what you mean by "ignored" ?
When you alter DHCP settings, these settings need to propagate to the clients.
You can force this by disconnecting & reconnecting network on the clients or reboot the clients.

EDIT: A test that you can run on a client PC (can be Windows or Linux client):

nslookup pi.hole <PIHOLE_IP_ADDRESS>

And when you leave out the "<PIHOLE_IP_ADDRESS>", below one should work as well if configured DHCP correctly:

nslookup pi.hole

Below an example with 10.0.0.2 being my Pi-hole setup:

C:\>nslookup pi.hole
Server:  noads.dehakkelaar.nl
Address:  10.0.0.2

Name:    pi.hole
Address:  10.0.0.2
9

Router: Cable modem from ISP, we supply our own router - RT-AC3200U. We use OpenDNS, Google or Level 3 DNS as our ISP has horrid DNS servers.

Ignore: All DNS then goes to whatever DNS settings we have for our Router WAN. I wonder if these did not propogate entirely to our local network. We did restart the router, pi-hole and each machine we tested on. Will need to try again to be certain.

Output from nslookup pi.hole (works on macOS too), with WAN and LAN pointing to pi-hole.

➜  ~ nslookup pi.hole
Server:		192.168.1.1
Address:	192.168.1.1#53

Name:	pi.hole
Address: 192.168.1.19

➜  ~ nslookup pi.hole 192.168.1.19
Server:		192.168.1.19
Address:	192.168.1.19#53

Name:	pi.hole
Address: 192.168.1.19

I should add, for the last 24 hours, the p-hole, with this setup is working very well. No more big logs. Still some significant traffic from NTP and SYNC, but not like the first day. Perhaps I am impatient in propagation?

10

You still have your router configured on the clients for DNS resolution and not Pi-hole's IP.
With the first nslookup, the Mac is querying the router 192.168.1.1 and not Pi-hole 192.168.1.19 like in the second nslookup.
Need to fix that first by configuring DHCP on the router or if not possible, disable LAN DHCP on the router and enable the DHCP service on Pi-hole:

EDIT: Not sure if works on a Mac but below one displays DNS server(s) used on Linux clients:

cat /etc/resolv.conf

11

Same on macOS.

So, I did not realize on macOS, that setting TCP/IP to fully manual meant it would not pull the DNS servers on it's own. Setting to DHCP with manual address, on the other hand, now pulls in the proper DNS, and a restart shows this works as expected. I'd forgotten I had hardcoded the DNS server on several machines probably a few years ago.

Feel wicked less smart now :frowning:

Apologies for being so slow on the uptake on this. Everything works precisely now as it should. Off to donate money to the pi-hole folks now.

2 Likes
12

I have that all the time :wink:

1 Like
13

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