bind: address already in use

[teletom]

Hi.

 

My AdGuard-Docker does not start anymore. I didn't change anything, just a reboot (I think so). 

 

It shows a fatal Error in Log from Docker: 

couldn't start forwarding DNS server: listening to udp socket: listen udp 0.0.0.0:53: bind: address already in use

 

My AdGurad Settings:

 

My Docker Allocations are: 

 

I guess is has something to do with 0.0.0.0 as IP... but I have no idea where to start fixing. 

 

If you need more information, just tell me. 

 

Thanks for your help!

 

Tom

[BasementGamer]

Did you figure out what's wrong? My server rebooted this morning due to a power outage, and now I can't start pihole with the same issue (docker: Error response from daemon: Address already in use.)

 

For some reason, when trying to find out what address might be in conflict, I found out that the unraid server is using port 53 with a strange IP (192.168.122.1), which isn't dhcp assigned, or even accessible outside of unraid.

[jombi]

Hi folks,

 

Sorry to hijack this thread, but I've just started having this same issue with my PiHole container. Initially it was working for a few days, and then after performing unraid OS upgrade from 6.11.4 to 6.11.5 the container wouldn't start (though the version change is likely unrelated and it could have been triggered by the reboot, but more info = more better).

 

Quote

docker: Error response from daemon: driver failed programming external connectivity on endpoint pihole (f23bf87352c946152f6111ec315aa0fda3858ea97f18b5dc392f5d755e6583e4): Error starting userland proxy: listen tcp4 0.0.0.0:53: bind: address already in use.

The command failed.

 

Using command  netstat -tunlp | grep ":53"  I can see that the port is in use by dnsmasq, so the error itself is obviously correct. I can see dnsmasq is listening on the same "strange IP address" referred to previously, but that just appears to be the virtual interface virbr0 address.

 

Using command  netstat -tunlp | grep "dnsmasq"  it looks like the only ports this process is listening for are the ones relating to the pihole container (TCP 53, UDP 53, and UDP 67)
 

Quote

 

~# netstat -tunlp | grep "dnsmasq"
tcp        0      0 192.168.122.1:53        0.0.0.0:*               LISTEN      7640/dnsmasq        
udp        0      0 192.168.122.1:53        0.0.0.0:*                           7640/dnsmasq        
udp        0      0 0.0.0.0:67              0.0.0.0:*                           7640/dnsmasq  

 

 

To my knowledge (unless there's a setting I haven't noticed), I don't have anything configured on the system that should be doing DNS/DHCP aside from the PiHole container. Which then leaves me with a series of questions:

1. Is it most likely that the dnsmasq service running and listening to these ports as a result of the creation of the container, or is it always running and listening on these ports on account of the fact that it is by it's nature a DNS/DHCP service?
2. It seems this service is running at bootup and listening on these ports. Is it possible/safe to either stop it from listening on these ports or stop it from running at bootup, or is it required for the container to work or even just something else in the system?
3. Are there any system logs somewhere that might indicate when this service was first started? I can only assume it was after my creation of the container, as I was obviously able to create and run it in the first place.

I'm by no means knowledgeable in Linux/unraid/Docker, so at this point I'm still trying to figure out what role dnsmasq plays in the system and I'm hoping people can forgive my ignorance if my questions/assumptions are way off the mark. Any direction I can get would be greatly appreciated as I'm probably heading down the completely wrong path here. Thanks for your time if you made it this far

 

EDIT:

After some further reading, I found that disabling VMs on the VM Manager page stops dnsmasq and allows the pihole container to run as normal. I think this might be related to a VM that I ran temporarily? After setting up PiHole I booted up pfSense in a VM but didn't really go anywhere with it and removed it after about 30 minutes, but it seems this is a lingering artifact of that setup.

 

In any case, it doesn't seem the issue is related to "Docker Engine", but I at least have some direction to investigate how to un-do whatever the VM did - leaving this here in the hopes this info helps someone else!

Edited November 28, 2022 by jombi
Found additional information

[ksp]

On 11/28/2022 at 6:30 AM, jombi said:

Hi folks,

 

Sorry to hijack this thread, but I've just started having this same issue with my PiHole container. Initially it was working for a few days, and then after performing unraid OS upgrade from 6.11.4 to 6.11.5 the container wouldn't start (though the version change is likely unrelated and it could have been triggered by the reboot, but more info = more better).

 

 

Using command  netstat -tunlp | grep ":53"  I can see that the port is in use by dnsmasq, so the error itself is obviously correct. I can see dnsmasq is listening on the same "strange IP address" referred to previously, but that just appears to be the virtual interface virbr0 address.

 

Using command  netstat -tunlp | grep "dnsmasq"  it looks like the only ports this process is listening for are the ones relating to the pihole container (TCP 53, UDP 53, and UDP 67)
 

 

To my knowledge (unless there's a setting I haven't noticed), I don't have anything configured on the system that should be doing DNS/DHCP aside from the PiHole container. Which then leaves me with a series of questions:

1. Is it most likely that the dnsmasq service running and listening to these ports as a result of the creation of the container, or is it always running and listening on these ports on account of the fact that it is by it's nature a DNS/DHCP service?
2. It seems this service is running at bootup and listening on these ports. Is it possible/safe to either stop it from listening on these ports or stop it from running at bootup, or is it required for the container to work or even just something else in the system?
3. Are there any system logs somewhere that might indicate when this service was first started? I can only assume it was after my creation of the container, as I was obviously able to create and run it in the first place.

I'm by no means knowledgeable in Linux/unraid/Docker, so at this point I'm still trying to figure out what role dnsmasq plays in the system and I'm hoping people can forgive my ignorance if my questions/assumptions are way off the mark. Any direction I can get would be greatly appreciated as I'm probably heading down the completely wrong path here. Thanks for your time if you made it this far

 

EDIT:

After some further reading, I found that disabling VMs on the VM Manager page stops dnsmasq and allows the pihole container to run as normal. I think this might be related to a VM that I ran temporarily? After setting up PiHole I booted up pfSense in a VM but didn't really go anywhere with it and removed it after about 30 minutes, but it seems this is a lingering artifact of that setup.

 

In any case, it doesn't seem the issue is related to "Docker Engine", but I at least have some direction to investigate how to un-do whatever the VM did - leaving this here in the hopes this info helps someone else!

Thank you for this information but I'm a little confused as to what a proper solution is for someone who needs VMs (running Home Assistant) and wants to have AdGuard Home on Docker.

[kennymc.c]

I also had this issue this night after the AdGuard container was stopped during a backup and did not started again. I restarted the server the Day before and also noticed this strange log message a few times during the first 30 minutes after the restart : "dnsmasq[14644]: failed to create listening socket for 192.168.122.1: Address already in use". Also in my network this address was not in use and also in a subnet, which i don't use at all.

After I disabled the VM service and activated it again, I was able to start the AdGuard container again. I haven't had a VM running for a while and they don't use the IP address mentioned.

Unfortunately, I now get the following message on the VM page: "Libvirt Service failed to start". If I delete the existing Libvirt image via the settings and restart the VM service, I no longer get an error message, but all my VMs are now gone. I then restored the libvrt image from a backup but then this error reoccurs. 

 

Update: I found an old backup I made via VM Backup and could replace the content of the xml and the .fd file. Fortunately I had changed only a few small things in the vm config in between.

Edited May 21, 2023 by kennymc.c

[kennymc.c]

Since I had the same problem again after a reboot last night, I did some more research and think I at least understand what is happening here.
Dnsmasq seems to launch with the VM service and tries to occupy port 53 on virtbr0 (192.168.122.1). Since the Docker service is probably started first, port 53 is already occupied by AdGuard/PiHole on all interface and the mentioned dnsmasq error messages occur.
As soon as the Docker container is stopped by the backup during the night and afterwards an attempt is made to restart it, dnsmasq has already taken over the port on virtbr0 in the meantime and the container cannot be restarted. Therefore, dnsmasq and thus also the VM service must be stopped. Then AdGuard/PiHole can use port 53 again.
However, after restarting the VM service, the libvrt error message occurs. Instead of deleting the image or loading a backup, you can simply restart the Docker service. Apparently though, after restarting the docker service, the virtbr0 interface disappears and needs to be restarted manually via a terminal command. This causes the dnsmasq messages to appear in the log again. This also explains why I have the problem only after a reboot, because virtbr0 simply no longer runs and restarts only automatically after a restart of the server, because here also the vm serivce is restarted.

I found about the disappearance of the virtbr0 interface here, but unfortunately the reason for this has not been found out yet:

 

Then I read this thread wich advices to run DNS servers via Docker on br0 with its own static IP address instead of Bridge or Host because these will occupy the containers ports on all interfaces which includes virtbr0 as well that is needed for vms.