FTL failed to start due to failed to create listening socket for port 53: Address already in use (by dnsmasq)

[fg5398]

The issue I am facing:

My pihole is unable to start its DNS service. In diagnostic on the web interface I get:

"FTL failed to start due to failed to create listening socket for port 53: Address already in use"

I've seen a lot of help threads where the issue has been connmand taking up port 53. When I run

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

it shows dnsmasq taking up this port.

Details about my system:

x64 machine running Debian

What I have changed since installing Pi-hole:

A whole bunch of stuff - it was running fine for nearly a year before it stopped working. No idea what it'll be.

[jfb]

@fg5398

it shows dnsmasq taking up this port

Stop and disable dnsmasq (and you can uninstall it).

Then restart pihole-FTL and it will bind to port 53.

[fg5398]

Thanks, so I had dnsmasq-base installed, I removed it via apt and restarted the pihole-FTL service through systemctl.

No change, port 53 is still coming up as in use by dnsmasq.

This is the message I get when running pihole -d if that helps:

DNSMASQ_CONFIG failed to create listening socket for port 53: Address already in use

[fg5398]

Resolved: I edited /etc/dnsmasq.conf to make the listening port 5353, restarted pihole-FTL and that removed the error. I then changed it back to port 53, restarted again and now it's working fine.

[Bucking_Horn]

@fg5398

No change, port 53 is still coming up as in use by dnsmasq.

That would imply that some dnsmasq process is still running on your machine.
You could verify that, e.g. with sudo ss -tulpn sport = 53.

@fg5398

(...) I had dnsmasq-base installed, I removed it via apt and restarted the pihole-FTL service through systemctl.

If you didn't stop and disable dnsmasq, that may have left the already running instance intact.

You may want to scrutinise your /etc/dnsmasq.conf as well, as that file usually only points to the configuration directory, i.e. it does not contain any port information.

And if some other dnsmasq would still be present, it's likely that your edit may only be a temporary fix, and the issue will be reintroduced by one of the next reboots.

In any case, applying jfb's advice is the correct way to address the issue of dnsmasq conflicting with Pi-hole (provided you are not depending on dnsmasq for other reasons).