pihole-FTL failed to create listening socket for port 53



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:

DNS service not running

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.


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.



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 (, so in theory it should not interfere with dnsmasq/FTL, as FTL should only listen on 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.


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'


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    *               LISTEN      719/lighttpd        
tcp        0      0    *               LISTEN      640/pihole-FTL      
tcp        0      0*               LISTEN      683/cloudflared     
tcp6       0      0 :::80                   :::*                    LISTEN      719/lighttpd        
tcp6       0      0 :::53                   :::*                    LISTEN      640/pihole-FTL      
udp        0      0*                           683/cloudflared     
udp        0      0  *                           685/stubby          
udp        0      0    *                           640/pihole-FTL      
udp        0      0    *                           640/pihole-FTL      
udp6       0      0 :::53                   :::*                                640/pihole-FTL


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.


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?


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.


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

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


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


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 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.


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.


I tried that now too, and gave stubby

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.


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


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


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