DNS-Resolver-Error after updating: There was a problem applying your settings. PHP error (2): fsockopen(): unable to connect to 127.0.0.1:4711 (Connection refused) in /var/www/html/admin/scripts/pi-hole/php/FTL.php:44

The pihole-FTL binary/daemon should be listening on that port:

pi@ph5b:~ $ sudo netstat -nltup | grep 'Proto\|:4711 '
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:4711          0.0.0.0:*               LISTEN      32260/pihole-FTL
tcp6       0      0 ::1:4711                :::*                    LISTEN      32260/pihole-FTL

And the web GUI is querying this port.
But pihole-FTL can only bind to that 127.0.0.1 IP if nothing wrong with it or no firewall blocking.

root@blackPI:~# nc -vz 127.0.0.1 4711
nc: connect to 127.0.0.1 port 4711 (tcp) failed: Connection refused
root@blackPI:~# nc -vz 127.0.0.1 14434
Connection to 127.0.0.1 14434 port [tcp/*] succeeded!
root@blackPI:~# ip -br a s lo
lo               UNKNOWN        127.0.0.1/8 
root@blackPI:~# 

see my posting above, no firewall
14434 is the server-port of my qBittorrent-Instance

by the way, see my EDIT above, it's not a network-issue, it's a problem of pihole, right?

Not sure.
Do you know why the IPv6 address ::1 is lacking?

pi@ph5b:~ $ ip -br a s lo
lo               UNKNOWN        127.0.0.1/8 ::1/128

EDIT: Ow ps, I dont think its related.
Wait for a dev or mod for a possible answer.

EDIT2: Aha I see:

@Bucking_Horn
do you have any update for me?
Is there anything that I can do?

Those results didn't produce any hints.
Could you also provide

ls -lah /var/log/pihole*.log

From your latest debug log mADg1Qm1, pihole-FTL is reported as running:

*** [ DIAGNOSING ]: Pi-hole processes
[✓] lighttpd daemon is active
[✓] pihole-FTL daemon is active
But at the same time, it seems it failed to bind any of its ports, 53 and 4711, and possibly 67 and 547 if Pi-hole has been configured for DHCP/DHCPv6 (click for debug log details):
*** [ DIAGNOSING ]: Ports in use
    udp:192.168.3.102:5353 is in use by dotnet
    udp:0.0.0.0:5353 is in use by dotnet
    udp:0.0.0.0:5353 is in use by avahi-daemon
    udp:0.0.0.0:3478 is in use by dotnet
    udp:0.0.0.0:59312 is in use by avahi-daemon
    udp:0.0.0.0:68 is in use by dhclient
    udp:192.168.98.1:14434 is in use by qbittorrent-nox
    udp:10.0.9.1:14434 is in use by qbittorrent-nox
    udp:10.0.8.1:14434 is in use by qbittorrent-nox
    udp:192.168.99.1:14434 is in use by qbittorrent-nox
    udp:192.168.3.102:14434 is in use by qbittorrent-nox
    udp:127.0.0.1:14434 is in use by qbittorrent-nox
    udp:0.0.0.0:55553 is in use by openvpn
    udp:0.0.0.0:530 is in use by iodined
    udp:0.0.0.0:51820 is in use by <unknown>
    udp:*:51820 is in use by <unknown>
    tcp:0.0.0.0:22 is in use by sshd
    tcp:0.0.0.0:8888 is in use by rpimonitord
    tcp:0.0.0.0:8090 is in use by dotnet
    tcp:0.0.0.0:666 is in use by apache2
    tcp:0.0.0.0:667 is in use by apache2
    tcp:0.0.0.0:2525 is in use by master
    tcp:0.0.0.0:55552 is in use by stunnel4
    tcp:192.168.98.1%wg0:14434 is in use by qbittorrent-nox
    tcp:10.0.9.1%tun1:14434 is in use by qbittorrent-nox
    tcp:10.0.8.1%tun0:14434 is in use by qbittorrent-nox
    tcp:192.168.99.1%dns0:14434 is in use by qbittorrent-nox
    tcp:192.168.3.102%wlan0:14434 is in use by qbittorrent-nox
    tcp:127.0.0.1%lo:14434 is in use by qbittorrent-nox
    tcp:0.0.0.0:55554 is in use by openvpn
    tcp:127.0.0.1:3306 is in use by mysqld
    tcp:0.0.0.0:5900 is in use by vncserver-x11-c
    tcp:0.0.0.0:45678 is in use by apache2
[✓] tcp:0.0.0.0:80 is in use by lighttpd
    tcp:[::]:22 is in use by sshd
    tcp:[::]:2525 is in use by master
    tcp:*:7777 is in use by qbittorrent-nox
    tcp:*:9090 is in use by systemd
    tcp:[::]:5900 is in use by vncserver-x11-c
[✓] tcp:[::]:80 is in use by lighttpd

There may be a port conflict over 5353 (avahi and dotnet both claiming the offcial mDNS port), but that certainly is not related to Pi-hole.

More often than not, that would suggest a firewall on the machine hosting Pi-hole would be blocking Pi-hole's ports.

But it's strange that pihole-FTL would not even log its new startup attempts, as your log still shows it as having been terminated on 2022-07-09 as its last entry:

*** [ DIAGNOSING ]: contents of /var/log/pihole
-rw-r--r-- 1 pihole pihole 4.9K Jul  9 09:21 /var/log/pihole/FTL.log

   -----tail of FTL.log------
   [2022-07-09 09:21:21.106 1522M] Shutting down...
   (...)
   [2022-07-09 09:21:21.430 1522M] ########## FTL terminated after 4d 16h 20m 2s  (code 0)! ##########

Below ones dump the rules in the nf_tables module:

sudo iptables -nL

sudo nft list tables

FYI:

pi@ph5b:~ $ lsmod
Module                  Size  Used by
nf_tables             200704  0
[..]
pi@ph5b:~ $ modinfo nf_tables
filename:       /lib/modules/5.10.92+/kernel/net/netfilter/nf_tables.ko
alias:          nfnetlink-subsys-10
author:         Patrick McHardy <kaber@trash.net>
license:        GPL
srcversion:     88909CB365A49A17A4E5873
depends:        nfnetlink
intree:         Y
name:           nf_tables
vermagic:       5.10.92+ mod_unload modversions ARMv6 p2v8
root@blackPI:/var/log# ls -lah /var/log/pihole*.log
lrwxrwxrwx 1 pihole pihole 23  9. Jul 09:21 /var/log/pihole-FTL.log -> /var/log/pihole/FTL.log
lrwxrwxrwx 1 pihole pihole 26  9. Jul 09:21 /var/log/pihole.log -> /var/log/pihole/pihole.log
root@blackPI:/var/log#
nothing

because the problem occured with an update of pihole, is it possible to downgrade?

regard the problem, what can I do help you to find the problem?

Could try below to see if anything out of the ordinary:

pi@ph5b:~ $ sudo -u pihole pihole-FTL debug
[2022-07-13 19:51:42.311 15229M] Using log file /var/log/pihole/FTL.log
[2022-07-13 19:51:42.314 15229M] ########## FTL started on ph5b! ##########
[2022-07-13 19:51:42.317 15229M] FTL branch: master
[2022-07-13 19:51:42.319 15229M] FTL version: v5.16.1
[2022-07-13 19:51:42.321 15229M] FTL commit: 5ff5bed
[2022-07-13 19:51:42.323 15229M] FTL date: 2022-07-08 08:44:12 +0100
[2022-07-13 19:51:42.324 15229M] FTL user: pihole
[2022-07-13 19:51:42.325 15229M] Compiled for armv6hf (compiled on CI) using arm-linux-gnueabihf-gcc (crosstool-NG crosstool-ng-1.22.0-88-g8460611) 4.9.3
[2022-07-13 19:51:42.328 15229M] Creating mutex
[2022-07-13 19:51:42.330 15229M] Creating mutex
[2022-07-13 19:51:42.339 15229M] Starting config file parsing (/etc/pihole/pihole-FTL.conf)
[2022-07-13 19:51:42.342 15229M]    SOCKET_LISTENING: only local
[2022-07-13 19:51:42.345 15229M]    AAAA_QUERY_ANALYSIS: Show AAAA queries
[2022-07-13 19:51:42.347 15229M]    MAXDBDAYS: max age for stored queries is 365 days
[2022-07-13 19:51:42.349 15229M]    RESOLVE_IPV6: Resolve IPv6 addresses
[2022-07-13 19:51:42.351 15229M]    RESOLVE_IPV4: Resolve IPv4 addresses
[2022-07-13 19:51:42.353 15229M]    DBINTERVAL: saving to DB file every minute
[2022-07-13 19:51:42.355 15229M]    DBFILE: Using /etc/pihole/pihole-FTL.db
[2022-07-13 19:51:42.357 15229M]    MAXLOGAGE: Importing up to 24.0 hours of log data
[2022-07-13 19:51:42.359 15229M]    PRIVACYLEVEL: Set to 0
[2022-07-13 19:51:42.361 15229M]    IGNORE_LOCALHOST: Show queries from localhost
[2022-07-13 19:51:42.362 15229M]    BLOCKINGMODE: Null IPs for blocked domains
[2022-07-13 19:51:42.363 15229M]    ANALYZE_ONLY_A_AND_AAAA: Disabled. Analyzing all queries
[2022-07-13 19:51:42.366 15229M]    DBIMPORT: Importing history from database
[2022-07-13 19:51:42.366 15229M]    PIDFILE: Using /run/pihole-FTL.pid
[2022-07-13 19:51:42.368 15229M]    PORTFILE: Using /run/pihole-FTL.port
[2022-07-13 19:51:42.370 15229M] WARNING: Unable to write used port to file
[2022-07-13 19:51:42.372 15229M]          (API might not find the port)
[2022-07-13 19:51:42.374 15229M]    SOCKETFILE: Using /run/pihole/FTL.sock
[2022-07-13 19:51:42.376 15229M]    SETUPVARSFILE: Using /etc/pihole/setupVars.conf
[2022-07-13 19:51:42.377 15229M]    MACVENDORDB: Using /etc/pihole/macvendor.db
[2022-07-13 19:51:42.379 15229M]    GRAVITYDB: Using /etc/pihole/gravity.db
[2022-07-13 19:51:42.381 15229M]    PARSE_ARP_CACHE: Active
[2022-07-13 19:51:42.383 15229M]    CNAME_DEEP_INSPECT: Active
[2022-07-13 19:51:42.385 15229M]    DELAY_STARTUP: No delay requested.
[2022-07-13 19:51:42.386 15229M]    BLOCK_ESNI: Enabled, blocking _esni.{blocked domain}
[2022-07-13 19:51:42.389 15229M]    NICE: Set process niceness to -10 (default)
[2022-07-13 19:51:42.390 15229M]    MAXNETAGE: Removing IP addresses and host names from network table after 365 days
[2022-07-13 19:51:42.392 15229M]    NAMES_FROM_NETDB: Enabled, trying to get names from network database
[2022-07-13 19:51:42.393 15229M]    EDNS0_ECS: Overwrite client from ECS information
[2022-07-13 19:51:42.394 15229M]    REFRESH_HOSTNAMES: Periodically refreshing IPv4 names
[2022-07-13 19:51:42.397 15229M]    RATE_LIMIT: Rate-limiting client making more than 1000 queries in 60 seconds
[2022-07-13 19:51:42.398 15229M]    LOCAL_IPV4: Automatic interface-dependent detection of address
[2022-07-13 19:51:42.401 15229M]    LOCAL_IPV6: Automatic interface-dependent detection of address
[2022-07-13 19:51:42.402 15229M]    BLOCK_IPV4: Automatic interface-dependent detection of address
[2022-07-13 19:51:42.405 15229M]    BLOCK_IPV6: Automatic interface-dependent detection of address
[2022-07-13 19:51:42.405 15229M]    SHOW_DNSSEC: Enabled, showing automatically generated DNSSEC queries
[2022-07-13 19:51:42.407 15229M]    MOZILLA_CANARY: Enabled
[2022-07-13 19:51:42.409 15229M]    PIHOLE_PTR: internal PTR generation enabled (pi.hole)
[2022-07-13 19:51:42.411 15229M]    ADDR2LINE: Enabled
[2022-07-13 19:51:42.413 15229M]    REPLY_WHEN_BUSY: Drop queries when the database is busy
[2022-07-13 19:51:42.415 15229M]    BLOCK_TTL: 2 seconds
[2022-07-13 19:51:42.417 15229M]    BLOCK_ICLOUD_PR: Enabled
[2022-07-13 19:51:42.418 15229M]    CHECK_LOAD: Enabled
[2022-07-13 19:51:42.420 15229M]    CHECK_SHMEM: Warning if shared-memory usage exceeds 90%
[2022-07-13 19:51:42.422 15229M]    CHECK_DISK: Warning if certain disk usage exceeds 90%
[2022-07-13 19:51:42.424 15229M] Finished config file parsing
[2022-07-13 19:51:42.435 15229M] Database version is 12
[2022-07-13 19:51:42.438 15229M] Resizing "FTL-strings" from 40960 to (81920 * 1) == 81920 (/dev/shm: 1.2MB used, 225.3MB total, FTL uses 1.2MB)
[2022-07-13 19:51:42.442 15229M] Imported 0 alias-clients
[2022-07-13 19:51:42.446 15229M] Database successfully initialized
[2022-07-13 19:51:42.490 15229M] New upstream server: 127.0.0.1:5335 (0/1024)
[2022-07-13 19:51:42.504 15229M] New upstream server: 10.0.0.2:53 (1/1024)
[2022-07-13 19:51:43.027 15229M] Resizing "FTL-queries" from 180224 to (8192 * 44) == 360448 (/dev/shm: 1.3MB used, 225.3MB total, FTL uses 1.3MB)
[2022-07-13 19:51:43.045 15229M] Imported 4230 queries from the long-term database
[2022-07-13 19:51:43.049 15229M]  -> Total DNS queries: 4230
[2022-07-13 19:51:43.051 15229M]  -> Cached DNS queries: 2657
[2022-07-13 19:51:43.054 15229M]  -> Forwarded DNS queries: 1103
[2022-07-13 19:51:43.056 15229M]  -> Blocked DNS queries: 318
[2022-07-13 19:51:43.058 15229M]  -> Unknown DNS queries: 0
[2022-07-13 19:51:43.059 15229M]  -> Unique domains: 254
[2022-07-13 19:51:43.060 15229M]  -> Unique clients: 4
[2022-07-13 19:51:43.062 15229M]  -> Known forward destinations: 2
[2022-07-13 19:51:43.064 15229M] Successfully accessed setupVars.conf
[2022-07-13 19:51:43.072 15229M] listening on 0.0.0.0 port 53
[2022-07-13 19:51:43.076 15229M] listening on :: port 53
[2022-07-13 19:51:43.083 15229M] WARNING: Unable to write PID to file.
[2022-07-13 19:51:43.086 15229M]          Continuing anyway...
[2022-07-13 19:51:43.089 15229M] PID of FTL process: 15229
[2022-07-13 19:51:43.093 15229M] INFO: FTL is running as user pihole (UID 999)
dnsmasq: [2022-07-13 19:51:43.095 15229/T15232] Listening on Unix socket
started, version pi-hole-2.87test8 cachesize 10000
dnsmasq: [2022-07-13 19:51:43.097 15229/T15231] Listening on port 4711 for incoming IPv6 telnet connections
[2022-07-13 19:51:43.097 15229/T15230] Listening on port 4711 for incoming IPv4 telnet connections
DNS service limited to local subnets
dnsmasq: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n IDN DHCP DHCPv6 Lua TFTP no-conntrack ipset no-nftset auth cryptohash DNSSEC loop-detect inotify dumpfile
dnsmasq: using nameserver 127.0.0.1#5335
dnsmasq: using nameserver 10.0.0.2#53 for domain 0.0.10.in-addr.arpa
dnsmasq: using nameserver 10.0.0.2#53 for domain home.dehakkelaar.nl
dnsmasq: using only locally-known addresses for onion
dnsmasq: using only locally-known addresses for bind
dnsmasq: using only locally-known addresses for invalid
dnsmasq: using only locally-known addresses for localhost
dnsmasq: using only locally-known addresses for test
[2022-07-13 19:51:43.124 15229M] Reloading DNS cache
dnsmasq: read /etc/hosts - 5 addresses
dnsmasq: read /etc/pihole/custom.list - 6 addresses
dnsmasq: read /etc/pihole/local.list - 0 addresses
[2022-07-13 19:51:43.318 15229/T15233] Compiled 0 whitelist and 2 blacklist regex filters for 4 clients in 106.7 msec
[2022-07-13 19:51:43.322 15229/T15233] Blocking status is enabled

Can stop by pressing CTRLc and start here up normal again with below:

pihole restartdns

1 Like

That was the solution.
The Setup of pihole do not check if rights on folder
/var
and
/var/log
are set correctly.

When you start it with sudo -u pihole pihole-FTL debug
the result:

[2022-07-14 00:19:16.302 26693M] Using log file /var/log/pihole/FTL.log
!!! WARNING: Writing to FTL's log file failed!
FATAL: Opening of FTL log (/var/log/pihole/FTL.log) failed!
       Make sure it exists and is writeable by user pihole

I am wondering why before update of pihole, everything worked well.
I never changed right on /var and /var/log after installing pihole first time.

I suppose that FTL could start also without writing logfile, or there was a change in coding of FTL in the update.

That somehow contradicts:

What were those permissions, and what did you change them to now?

ls -lahd /var /var/log

Have a look on the timestamp of the log-File, and the last entry in log-file --> 09th July

That was exactly the date/time when I made the update via pihole up
So, something happend while update.
Before, FTL had a working access to /var/log/pihole/FTL.log. So the update changed something.

After Update, i noticed immediately that one logfile in /var/log/pihole had root as owner and group, not pihole (I dont remember which file).
That's why I mentioned in my first posting that i started pihole up with root-user.

Between 9th July and today, you released a new version of pihole to correct the non-working log-rotation.
I suppose that another effect of the rotations-error was that the rights of /var/log were changed.

Owner and Group of /var and /var/log is root
because pihole and FTL work with user pihole, pihole user can only access FTL-log when /var and /var/log/ have the allowance to read and list these folders for "others" ("r" and "x" for others)

I am fully aware of that.
See my very first reply here:

Note that even your first debug log contained the correct permissions for both of the log files, which have always been listed correctly since.

It doesn't seem likely that permissions on those files have been the cause for your observation, which leaves me without an explanation for that recent FATAL error of yours. :confused:

EDIT:
That leaves /var/log/pihole/ (the new target directory for Pi-hole's log files) as a possibilty for incorrect permissions:

~$ ls -lahd /var/log/pihole
drwxr-xr-x 2 pihole pihole 4.0K Jul 14 00:00 /var/log/pihole

correct, the log-function only shows the rights of folder pihole and the files itself, but not the folder above

by the way, what do you mean with new directory?
Did you changed the folder in the update?

Yes, as noted in the release notes.

https://pi-hole.net/blog/2022/07/07/pi-hole-ftl-v5-16-web-v5-13-and-core-v5-11-1-released/

No, the debug log does not contain directory permissions at all, only files.

But I realise now that I should have spotted that deviation from the results of one of the commands I've asked you to run - my bad:

as opposed to:

Still, I do not have an explanation how that directory may have ended up with wrong permissions. It certainly was created correctly when I did my updates..

Same here.

@blacksun , I wonder if you use some sort of logtoram or tmpfs for the logs that might kick in too late or interfere otherwise.
What does below one show?

findmnt

i developed some thoughts
I think you do neither check folder-permissions nor change permissions on them, right?

If an Update for pihole is available, this cannot be done with user pihole.
So everybody has to use a higher privileged user, root, pi, etc.
these user has always access to the folders and files which pihole.
So you do not notice wrong permissions. When running pihole as service, the pihole user is used. So if there is a permission-problem, this occurs only when running in normal mode.

Because nobody else than me had the problem, I think you do not have to change anything.
For the future, an idea would be a permission check on all folders which are used by pihole. This check should check for permission for pihole user.
This check should run while installation, and also when updating.

No, the update script explicitly creates the new folder with the required permissions.

But you may have a point, in the unlikely event that it wasn't Pi-hole creating that folder:
One possible explanation for your observation would be that you've created that folder manually.
This has been suggested in FTL log move error during latest update (Pi-hole FTL v5.16, Web v5.13 and Core v5.11.1) - #6 by yubiuser as a workaround for a glitch that was introduced by an early Pi-hole FTL v5.16, Web v5.13 and Core v5.11.1 released, which has since been addressed in the meantime.

Did you perhaps apply that workaround and create the folder manually, perhaps while logged in as root?

No again - the update process takes care of rights and permissions.
As suggested by our update note, running pihole -up is enough - no need to switch to another user:
update-available

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