pihole-FTL failed to create listening socket for port 53

#1

Hi,

as pihole does not provide dns privacy using DNS-over-TLS (DoT), I used older versions of pi-hole together with the dns proxy stubby (DoT). After switching to pihole-FTL, this doesnt seem to work anymore. I checked two different pihole installations, and both complain “failed to create listening socket for port 53 : Address already in use”. After stopping and disabling stubby using systemctl, pihole-FTL works again as expected.

Is there anything I can do about this?

best regards, and thank you for this nice peace of software :slight_smile:

0 Likes

DNS service not running
#2

In Pi-Hole V4.0 and later, dnsmasq is embedded in pihole-FTL, and dnsmasq no longer runs as a separate process. The debug log will show dnsmasq as either failed or inactive. Process pihole-FTL should be shown running on port 53.

https://docs.pi-hole.net/ftldns/dns-resolver/

Since dnsmasq is now embedded in pihole-FTL, existing dnsmasq configuration files will work as before, assuming they are compatible with dnsmasq V2.80. You should look on the stubby site for a guide which is more recent and works with Pi-Hole V4 and later.

You also have other options for encrypted DNS. There is a guide on the Pi-Hole documentation site for installing DNS over HTTPS with Cloudflared.

https://docs.pi-hole.net/guides/dns-over-https/

0 Likes

#3

Thank you for your fast answer :slight_smile:

I did not change any configs of dnsmasq, nor did I change configs of pihole-FTL. And stubby has got his own loopback address and port (127.0.0.11), so in theory it should not interfere with dnsmasq/FTL, as FTL should only listen on 127.0.0.1. Still pihole-FTL complains, as long as stubby.service is enabled.

I just cross checked with cloudflared. Same problem:

sudo systemctl enable cloudflared

sudo reboot

sudo systemctl status pihole-FTL
[…]
failed to create listening socket for port 53 : Address already in use

If I do this:

sudo systemctl disable cloudflared
sudo systemctl stop pihole-FTL
sudo systemctl start pihole-FTL

pihole-FTL works as expected.

0 Likes

#4

What is the output of this command - something is on port 53 and preventing Pi-Hole from being on that port:

sudo netstat -nltup | grep 'Proto\|:53 \|:67 \|:80 \|:471'

0 Likes

#5

I added port 5053 (cloudflared)

netstat -nltup | grep 'Proto\|:53 \|:67 \|:80 \|:471 \|5053'

This is the output:

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      719/lighttpd        
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      640/pihole-FTL      
tcp        0      0 127.0.0.1:5053          0.0.0.0:*               LISTEN      683/cloudflared     
tcp6       0      0 :::80                   :::*                    LISTEN      719/lighttpd        
tcp6       0      0 :::53                   :::*                    LISTEN      640/pihole-FTL      
udp        0      0 127.0.0.1:5053          0.0.0.0:*                           683/cloudflared     
udp        0      0 127.0.0.2:53            0.0.0.0:*                           685/stubby          
udp        0      0 0.0.0.0:53              0.0.0.0:*                           640/pihole-FTL      
udp        0      0 0.0.0.0:67              0.0.0.0:*                           640/pihole-FTL      
udp6       0      0 :::53                   :::*                                640/pihole-FTL
0 Likes

#6

Meanwhile I found a workaround for my setup:
I slow down the start of stubby.service and cloudflared.service
by adding “Type=idle” to the corresponding unit files.

After doing so, and rebooting, pihole-FTL does not complain.
I then add stubby as the only upstream dns server to pihole,
and dns service works again as expected.

0 Likes

#7

Do you consider addressing the underlying problem?

The workaround seems to work for my setup so far,
but to me, something seems wrong under the hoods.
How can a dns proxy stop pihole-FTL from working,
if they both use different loopback adresses for listening?

0 Likes

#8

You started with an older version of Pi-Hole and likely an old version of Stubby. Without knowing all the details of your configuration, it is difficult to determine why the conflict exists.

0 Likes

#9

I compiled stubby 0.25 from source. I installed cloudflares own binary.
Both proxys work seamlessly, if queried directly like this:
dig @127.0.0.1 -p 5053 pi-hole.net)

I could start from scratch, if that would be of help.

0 Likes

#10

I don’t think that’s required. Sounds like your problem is resolved.

0 Likes

#11

Hi again,

I was curious and have rechecked the steps on a spare sd-card using current raspbian (stretch):

  • installed current pi-hole 4.2.1: pi-hole dns service works
  • installed current stubby from source, listening address 127.0.02: stubby works, pi-hole dns service works
  • configured 127.0.0.2#53 as upstream dns server in pi-hole web ui: pi-hole dns service works
  • restarted raspberry pi: pi-hole dns service does not work :expressionless: |
  • added “Type=idle” to stubby.service: pi-hole dns does not work (although this helped on two other systems as metioned above)

home/pi# service pihole-FTL status -l
**●** pihole-FTL.service - LSB: pihole-FTL daemon
Loaded: loaded (/etc/init.d/pihole-FTL; generated; vendor preset: enabled)
Active: **active (exited)** since Thu 2019-02-14 14:05:16 CET; 42s ago
Docs: man:systemd-sysv-generator(8)
Process: 355 ExecStart=/etc/init.d/pihole-FTL start (code=exited, status=0/SUCCESS)
Feb 14 14:05:03 cube systemd[1]: Starting LSB: pihole-FTL daemon...
Feb 14 14:05:03 cube pihole-FTL[355]: Not running
Feb 14 14:05:15 cube su[1174]: Successful su for pihole by root
Feb 14 14:05:15 cube su[1174]: + ??? root:pihole
Feb 14 14:05:15 cube su[1174]: pam_unix(su:session): session opened for user pihole by (uid=0)
Feb 14 14:05:16 cube pihole-FTL[355]: dnsmasq: failed to create listening socket for port 53: Address already in use
Feb 14 14:05:16 cube systemd[1]: Started LSB: pihole-FTL daemon.

To me, there seems to be a bug in dnsmasq/pihole-FTL, when it comes to opening the listening port.

I’d love to help more. Drop me a line, if I can help with more data.

0 Likes

#12

Have you tried putting Stubby on a different port? This behavior is in dnsmasq, so if it is a bug, it is not a Pi-hole bug.

0 Likes

#13

I tried that now too, and gave stubby 127.0.0.2:10053.

After a reboot, pihole dns service does not work, the service just dies while starting:

service pihole-FTL status -l
● pihole-FTL.service - LSB: pihole-FTL daemon
Loaded: loaded (/etc/init.d/pihole-FTL; static; vendor preset: enabled)
Active: inactive (dead)
Docs: man:systemd-sysv-generator(8)

Then i run
pihole -r
And pihole dns service works as expected.

0 Likes

#14

Are you using Stubby or Cloudflared for your encrypted DNS (or both)? You noted that both were installed, but are you using both?

0 Likes

#15

On one of the systems, cloudflared is installed (127.0.0.1:5053), but disabled using systemctl.
The third system I am talking about in my last posts does not contain cloudflared.

0 Likes

#16

What is the output of this command? journalctl -u pihole-FTL
There must be some reason it does not start.

0 Likes

#17

There is no error message at all:

service pihole-FTL status -l
● pihole-FTL.service - LSB: pihole-FTL daemon
Loaded: loaded (/etc/init.d/pihole-FTL; static; vendor preset: enabled)
Active: inactive (dead)
Docs: man:systemd-sysv-generator(8)
root@cube:/home/pi# journalctl -u pihole-FTL
– Logs begin at Tue 2019-02-19 16:14:10 CET, end at Tue 2019-02-19 16:20:01 CET
– No entries –

0 Likes

#18

The logs were rotated 6 minutes before you ran that command. Please run sudo service pihole-FTL restart and then the journalctl command again.

0 Likes

#19

After a reboot, pihole-FTL does not work, and journal is empty. I have reproduced this several times now:

service pihole-FTL status -l
● pihole-FTL.service - LSB: pihole-FTL daemon
   Loaded: loaded (/etc/init.d/pihole-FTL; static; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:systemd-sysv-generator(8)
root@cube:/home/pi# journalctl -u pihole-FTL
-- Logs begin at Wed 2019-02-20 16:35:47 CET, end at Wed 2019-02-20 16:52:18 CET. 
-- No entries --

After restarting the service, pihole works as expected. No pihole-FTL errors in journal:

service pihole-FTL restart
root@cube:/home/pi# service pihole-FTL status -l
● pihole-FTL.service - LSB: pihole-FTL daemon
   Loaded: loaded (/etc/init.d/pihole-FTL; static; vendor preset: enabled)
   Active: active (exited) since Wed 2019-02-20 16:54:17 CET; 4s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 827 ExecStart=/etc/init.d/pihole-FTL start (code=exited, status=0/SUCCE

journalctl -u pihole-FTL
Feb 20 16:54:06 cube systemd[1]: Starting LSB: pihole-FTL daemon...
Feb 20 16:54:06 cube pihole-FTL[827]: Not running
Feb 20 16:54:17 cube su[880]: (to pihole) root on none
Feb 20 16:54:17 cube su[880]: pam_unix(su:session): session opened for user pih
Feb 20 16:54:17 cube pihole-FTL[827]: FTL started!
Feb 20 16:54:17 cube su[880]: pam_unix(su:session): session closed for user pih
Feb 20 16:54:17 cube systemd[1]: Started LSB: pihole-FTL daemon.

This seems to me in line with delaying the stubby.service for 30 seconds like mentioned here:

0 Likes

#20

btw: where does dnsmasq write its logs to?

0 Likes