I have pi-hole running on a NAS through docker and paired with tailscale (for mobile blocking). I recently had a power outage and after that I noticed that was pi-hole exited with an error " pi-hole conflict with port 53". I checked what what listening to port 53 and it showed a seperate IP other than than my host IP (192.100.0.1, not a 192.168.x.x address). Through another post, I added my host IP to the port in the docker compose(e.g 192.168.0.60:53:53 instead of just 53:53) for both tcp and udp and that fixed the docker instance but now Im getting no quiries. Im pretty sure this is an issue with dnsmasq, the log after doing docker -d seems to support that. I tried sudo systemctl status -l dnsmasq and it returns:
× dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
Loaded: loaded (/lib/systemd/system/dnsmasq.service; disabled; preset: enabled)
Active: failed (Result: exit-code) since Mon 2025-06-23 19:39:46 MDT; 29min ago
Process: 27001 ExecStartPre=/usr/share/dnsmasq/systemd-helper checkconfig (code=exited, status=0/SUCCESS)
Process: 27006 ExecStart=/usr/share/dnsmasq/systemd-helper exec (code=exited, status=2)
CPU: 44ms
Jun 23 19:39:46 BabyGotBytes systemd[1]: Starting dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server...
Jun 23 19:39:46 BabyGotBytes systemd-helper[27006]: dnsmasq: failed to create listening socket for port 53: Address already i>
Jun 23 19:39:46 BabyGotBytes dnsmasq[27006]: failed to create listening socket for port 53: Address already in use
Jun 23 19:39:46 BabyGotBytes dnsmasq[27006]: FAILED to start up
Jun 23 19:39:46 BabyGotBytes systemd[1]: dnsmasq.service: Control process exited, code=exited, status=2/INVALIDARGUMENT
Jun 23 19:39:46 BabyGotBytes systemd[1]: dnsmasq.service: Failed with result 'exit-code'.
Jun 23 19:39:46 BabyGotBytes systemd[1]: Failed to start dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS serve>
Here is whats on port 53, after I added my host IP to the docker compose:
tcp 0 0 192.168.0.60:53 0.0.0.0:* LISTEN 5010/docker-proxy
tcp 0 0 192.100.0.1:53 0.0.0.0:* LISTEN 1359/dnsmasq
udp 0 0 192.168.0.60:53 0.0.0.0:* 5076/docker-proxy
udp 0 0 192.100.0.1:53 0.0.0.0:* 1359/dnsmasq
Prior to adding my host IP, it was just the 192.100.0.1 IP.
Not sure what that IP is, I checked connections to my router and there is nothing out of the ordinary connected. They are all 192.168.x.x addresses. I also restarted my NAS a couple times and the connection is still there.
Token:
https://tricorder.pi-hole.net/q0B4x7BU/
I'm still a bit green diagnosing Docker but above one was run in a shell on the NAS and not in the container am I right?
Below on my Syno NAS that has systemd as init where you can use the systemctl command:
$ readlink -f /sbin/init
/usr/lib/systemd/systemd
Vs in a container running on the NAS:
$ sudo docker exec -it pihole6 readlink -f /sbin/init
/bin/busybox
The dnsmasq binary/daemon hasnt been used by Pi-hole for ages.
The dnsmasq code is embedded in the pihole-FTL binary nowadays:
$ sudo docker exec -it pihole6 pihole-FTL -vv
[..]
****************************** dnsmasq ******************************
Version: pi-hole-v2.90+2
Features: IPv6 GNU-getopt no-DBus no-UBus no-i18n IDN2 DHCP DHCPv6 Lua TFTP no-conntrack ipset no-nftset auth cryptohash DNSSEC loop-detect inotify dumpfile
[..]
$ sudo docker exec -it pihole6 ss -nltup sport = 53
Netid State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
udp UNCONN 0 0 0.0.0.0:53 0.0.0.0:*
udp UNCONN 0 0 *:53 *:*
tcp LISTEN 0 32 0.0.0.0:53 0.0.0.0:*
tcp LISTEN 0 32 *:53 *:*
$ sudo netstat -nltup | grep 'Proto\|pihole-FTL\|dnsmasq'
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:8181 0.0.0.0:* LISTEN 24946/pihole-FTL
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 24946/pihole-FTL
tcp6 0 0 :::53 :::* LISTEN 24946/pihole-FTL
udp 0 0 0.0.0.0:53 0.0.0.0:* 24946/pihole-FTL
udp6 0 0 :::53 :::* 24946/pihole-FTL
So if you have dnsmasq running on the NAS, its not coming from the Pi-hole container.
It might be running as a stub resolver for caching or for some other software running on the NAS that depends on dnsmasq.
EDIT: Maybe below one shows which unit/service depends on it:
systemctl list-dependencies --reverse dnsmasq.service
Thank you. That was the hint that I needed, I didnt know that dnsmasq was imbedded in pi-hole and not using the local service. Turns out that the local service dnsmasq was reserving port 53 and for some reason it was persisting through restarts even though it was reporting back an error for not being able to reserve port 53. I killed dnsmasq and now pi-hole is running fine. As far as Im away, nothing running locally needs dnsmasq so no great loss. It probably broke something obscure but thats future me problems.
1 Like
If it aint breaking anything, you could mask the unit/service eg:
sudo systemctl mask --now dnsmasq.service
FYI:
$ man systemctl
[..]
mask UNIT...
Mask one or more units, as specified on the command line. This
will link these unit files to /dev/null, making it impossible
to start them. This is a stronger version of disable, since it
prohibits all kinds of activation of the unit, including
enablement and manual activation. Use this option with care.
This honors the --runtime option to only mask temporarily until
the next reboot of the system. The --now option may be used to
ensure that the units are also stopped. This command expects
valid unit names only, it does not accept unit file paths.
Note that this will create a symlink under the unit's name in
/etc/systemd/system/ (in case --runtime is not specified) or
/run/systemd/system/ (in case --runtime is specified). If a
matching unit file already exists under these directories this
operation will hence fail. This means that the operation is
primarily useful to mask units shipped by the vendor (as those
are shipped in /lib/systemd/system/ and not the aforementioned
two directories), but typically doesn't work for units created
locally (as those are typically placed precisely in the two
aforementioned directories). Similar restrictions apply for
--user mode, in which case the directories are below the user's
home directory however.
unmask UNIT...
Unmask one or more unit files, as specified on the command
line. This will undo the effect of mask. This command expects
valid unit names only, it does not accept unit file paths.