-
-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[fatal] couldn't start forwarding DNS server #385
Comments
Facing the same problem with a little-bit different error for me. it is
This change makes it looking for ::1 even IPv6 is disable. |
I have the same issue and had to revert back to Adguard Home 4.7.6 from 4.8.0 due to this error message: [fatal] couldn't start forwarding DNS server: listening to udp socket: listen udp 127.0.0.1:53: bind: address already in use Also, this file (BEFORE UPGRADING FROM 4.7.6 to 4.8.0): /usr/share/hassio/addons/data/a0d7b954_adguard/adguard/AdGuardHome.yaml contents are:
Note, when I upgrade to 4.8.0, the above file appears to be the same except the bind_hosts section changes to only the IP address 127.0.0.1 - and I saw in suport forums in the past that people would change it to 0.0.0.0 and restart Adguard and it would then change to the host IP where adguard is running (in my case an RPI 4B 8G RAM w/a 1TB SSD Home Assistant Supervised which has the IP address 192.168.0.34). I am NOT using adguard as a dhcp server. I also tried changing the AdGuardHome.yaml to include the two IP addresses above and restart it - but the section in the file just changes to the one entry 192.168.0.34 - and also still has the same error message about port 53. BTW, I did a search as it looked like the port 53 was already being used by something else and all I could find for processes using port 53 was systemd_resolved but I think that was leading me down a rabbit hole as it wasn't really the issue - nothing else had changed in the configuration.... (BTW I also tried temporarily disabling the core_dns_override addon but that made zero difference.) Here is my setup currently:
|
I have exactly the same problem after the upgrade. Is there a way to manually specify the bind_hosts? If I rewrite the AdGuardHome.yaml file, it gets rewritten again when the addon starts. |
Searching with The solution may be to add this function to the changed file
and then, the actual row 60, change like this:
or something like that |
I have the same problem, i downgraded the addon to restore adguard. The system has the following configuration: fixed ip 192.168.2.51/32, gw 192.168.2.1, dns 192.168.2.51, ipv6 disabled, router 192.168.2.1 with dns server 192.168.2.51. With version 4.7.8 everything works perfectly. |
Same problem. |
Meanwhile I found a server configuration solution: |
I am happy for you! |
Anyway with version 4.7.8 everything works perfectly and adguard listens in the following ports: With version 4.8 I have the same problem as @patanachai with the following message in the log: "listen udp [::1]:53: bind: cannot assign requested address" |
@uroh armbian is not a supported installation method. |
@naked-head good catch. Home assistant supervisor only supports NetworkManager anyway, so your installation is not supported anyway. |
It would probably help us troubleshoot better if people post their system information: settings -> system -> repairs -> the three dots in the top right -> system information -> copy button in the bottom right. |
I honestly don't know why I have ConnMan, I thought it was a homeassistant dependence. I did a fresh clean install with Homeassistant Supervised and nothing more....I will investigate on it... Anyway the solution, if no change are made to this new version, is to stop the service (whatever it is) that lock the socket. that's my system: System Information
Home Assistant Community Store
Home Assistant Cloud
Home Assistant Supervisor
Dashboards
Recorder
|
Here is my system info for troubleshooting. For the time being I reverted back to the older version. If you need more specific info I would be happy to provide that. System Information
Home Assistant Community Store
Home Assistant Cloud
Home Assistant Supervisor
Dashboards
Recorder
Sonoff
Spotify
Xiaomi Miot Auto
|
Thank you @tjorim for the valuable contribution. However, I have taken the liberty of writing to request a different type of contribution aimed at resolving a problem that was not present in the previous version. Perhaps the implementation of binding to localhost is only oriented towards specific supported distributions or, perhaps, it contains some imperfections! In any case, I will be publishing the specifications of my unsupported server: System Information
Home Assistant Community Store
Home Assistant Cloud
Home Assistant Supervisor
Dashboards
NextDNS
Recorder
Sonoff
Xiaomi Miot Auto
|
Hi, I have the same issue: 2023/01/22 09:09:05.912562 [fatal] couldn't start forwarding DNS server: listening to udp socket: listen udp [::1]:53: bind: cannot assign requested address 23-01-22 09:43:38 WARNING (MainThread) [supervisor.addons.addon] Watchdog found addon AdGuard Home is failed, restarting... Debian 11 kernel version: 5.15.84-v8+ [root@raspberrypi:~]# ss -tulpen | grep ":53 " [root@raspberrypi:~]# systemctl status systemd-resolved.service Jan 22 19:16:16 raspberrypi systemd[1]: Starting Network Name Resolution... Any logic explanation why this localhost change has been provided? I do not see any option to disable it on Adguard Home addon level in Home Assistant Supervised. |
Today I have removed ConnMan going back to NetworkManager, my installation is now supported. AdGuard is still working even uninstalling I removed the only change I played in systemd configuration file of ConnMan, so with supported installation everything work well. Anyway I think that would be better if people can choose if AdGuard can listen on localhost or not. Using the correction I suggested before, or better adding a new configuration parameter. |
Just to add to this issue, unlike @naked-head I am not using ConnMan, but I have NetworkManager, my installation should be supported running on Debian 11. Yet I still get this error, exactly this one:
So I don't think it is only the ConnMan causing that. My only help was to revert back to the older version.
|
I am going to test the solution for the systemd-resolved from here: https://github.com/AdguardTeam/AdGuardHome/wiki/FAQ#why-am-i-getting-bind-address-already-in-use-error-when-trying-to-install-on-ubuntu I am using Debian 11 and I observed the same behavior. Probably when I will disable the service, Supervised will inform me that I am running unsuppoeted version. :) But I can live with it. |
@sysadmin-info I tried your solution, but that unfortunately didn't help.
Only now the 127.0.0.53:53 is gone from the netstat:
This is running the old version after your suggestion. Of course after upgrade there is nothing coming up because Adguard won't start. |
@InToSSH have you tried running The issue is binding UDP port 53; your netstat is only showing TCP |
@caraar12345 Yes, sorry, I just copied the wrong part. This is what it looks like after disabling systemd-resolved by applying the fix from AdGuard wiki:
The result is the same. After the AdGuard update the above command doesn't return anything. EDIT: I think I found some lead on what might be causing the issue. I checked the
for some reason even with this my main interface was getting IPv6 address, but the loopback doesn't seem to have it. |
Is it correct/normal to have the address 127.0.0.53:53? Shouldn't it be 127.0.0.1:53? |
Yes that is a normal behavior of systemd-resolved. The 127 A Class network is a loopback network a basically you can use anything in that subnet and it will work, so you can even ping |
@InToSSH, Looks like you've been to my house as well, as I've discovered a similar setup on my server. I took this opportunity to get my distro running smoothly with the home assistant. It is now fully supported except for the installation process. :) System Information
Home Assistant Community Store
Home Assistant Cloud
Home Assistant Supervisor
Dashboards
NextDNS
Recorder
Sonoff
Xiaomi Miot Auto
|
You did restart the systemd-resolved without changing the resolved.conf. There is the whole guide and is explained what and how to modify resolv.conf. Do this, then upgrade Adguard Home and perform a check, please. Now it shows me the 502 bad gateway. I diabled the systemd-resolved.service but it did not solve the problem. |
How to roll back? |
For me it is sometimes crashing like below, maybe it is a hint. I run HA Supervised on RPi4. Previous version of AdGuard worked perfectly... :/
With previos version all worked fine:
|
what do you see with the "ip a" command? |
|
It is because you have a read only system. Probably there is a problem with a low voltage or too many devices connected via USB or GPIO issue like maybe you connected something wrongly through GPIO like I do not know a relay or mosfet and there is a problem with voltage. Anyway because of some reason system went into read only mode. This is a normal behavior of the Raspberry Pi I experienced in past when I was playing with mosfets and relays through GPIO. |
its a laptop, not a pi :( |
I can recommend you to read this thread: https://askubuntu.com/questions/197459/how-to-fix-sudo-unable-to-open-read-only-file-system I hope you will solve your problem. |
There hasn't been any activity on this issue recently, so we clean up some of the older and inactive issues. |
I just want to point out this is still an issue for at least a few people, myself included.
I believe this was the start of the issue. It would be nice if we had the option to disable listening on localhost... Failure (using port 53, default):
Success (using port 54):
I also see in the generated config file where it is setting these interfaces (and I'd change it there, if it didn't get overwritten on every restart of the addon): |
I have a feeling if I disable resolvd then it will succeed. But if I do, then HomeAssistant will report my system is out of compliance. |
There hasn't been any activity on this issue recently, so we clean up some of the older and inactive issues. |
Same, similar problem with latest versions of adguard and HA OS. s6-rc: info: service s6rc-oneshot-runner: starting
|
Hi,
Check what listens on port 53, because some process is already listening
and Adguard cannot bind port 53 on udp.
sudo ss -tulpn | grep " 53"
wt., 16 maj 2023, 05:48 użytkownik reddog-42 ***@***.***>
napisał:
… Same, similar problem with latest versions of adguard and HA OS.
It was working until I loaded latest OS.
Tried fixing with latest Adguard, but no success.
Disabled and reenabled IPV6 to get ::1 active similar to above, but still
unable to listed on ip4 addr.
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service base-addon-banner: starting Add-on: AdGuard Home
Network-wide ads & trackers blocking DNS server Add-on version: 4.8.6
You are running the latest version of this add-on.
System: Home Assistant OS 10.1 (aarch64 / raspberrypi4-64)
Home Assistant Core: 2023.5.3
Home Assistant Supervisor: 2023.04.1 Please, share the above information
when looking for help
or support in, e.g., GitHub, forums or the Discord chat.
s6-rc: info: service base-addon-banner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service base-addon-log-level: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service base-addon-log-level successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service init-nginx: starting
s6-rc: info: service init-adguard: starting
s6-rc: info: service init-nginx successfully started
s6-rc: info: service init-adguard successfully started
s6-rc: info: service adguard: starting
s6-rc: info: service adguard successfully started
s6-rc: info: service discovery: starting
s6-rc: info: service nginx: starting
s6-rc: info: service nginx successfully started
[13:41:24] INFO: Starting AdGuard Home server...
2023/05/16 13:41:24.594626 [info] AdGuard Home, version v0.107.29
2023/05/16 13:41:24.595053 [info] AdGuard Home updates are disabled
2023/05/16 13:41:24.607520 [info] tls: using default ciphers
2023/05/16 13:41:24.629356 [info] safesearch default: reset 253 rules
2023/05/16 13:41:24.650390 [info] Initializing auth module:
/data/adguard/data/sessions.db
2023/05/16 13:41:24.656320 [info] auth: initialized. users:0 sessions:0
2023/05/16 13:41:24.656387 [info] web: initializing
2023/05/16 13:41:24.992238 [info] dnsproxy: cache: enabled, size 4096 b
2023/05/16 13:41:24.992286 [info] MaxGoroutines is set to 300
2023/05/16 13:41:24.992576 [info] AdGuard Home is available at the
following addresses:
2023/05/16 13:41:24.992613 [info] go to http://127.0.0.1:45158
[13:41:25] INFO: Starting NGinx...
[13:41:25] INFO: Successfully send discovery information to Home Assistant.
s6-rc: info: service discovery successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
2023/05/16 13:41:27.320098 [info] Starting the DNS proxy server
2023/05/16 13:41:27.320321 [info] Ratelimit is enabled and set to 20 rps
2023/05/16 13:41:27.320471 [info] The server is configured to refuse ANY
requests
2023/05/16 13:41:27.320619 [info] dnsproxy: cache: enabled, size 4194304 b
2023/05/16 13:41:27.320772 [info] MaxGoroutines is set to 300
2023/05/16 13:41:27.320930 [info] Creating the UDP server socket
2023/05/16 13:41:27.321274 [info] Listening to udp://10.0.0.38:53
2023/05/16 13:41:27.321437 [info] Creating the UDP server socket
2023/05/16 13:41:27.321788 [info] Listening to
udp://[fd51:2d59:96c1:1::d4b]:53
2023/05/16 13:41:27.321986 [info] Creating the UDP server socket
2023/05/16 13:41:27.322562 [info] Listening to
udp://[2403:xxxx:8d93:1::d4b]:53
2023/05/16 13:41:27.322861 [info] Creating the UDP server socket
2023/05/16 13:41:27.323467 [info] Listening to
udp://[2403:xxxx:8d93:1:7a69:3598:f731:fe5c]:53
2023/05/16 13:41:27.323770 [info] Creating the UDP server socket
2023/05/16 13:41:27.324242 [info] Listening to
udp://[fd51:2d59:96c1:1:3ed1:1684:ec17:e237]:53
2023/05/16 13:41:27.324544 [info] Creating the UDP server socket
2023/05/16 13:41:27.329225 [fatal] couldn't start forwarding DNS server:
listening to udp socket: listen udp 10.0.0.38:53: bind: address already
in use
[13:41:27] INFO: Service Adguard Home exited with code 1 (by signal 0)
—
Reply to this email directly, view it on GitHub
<#385 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFULAOUYGDQ4II3MMXTUSVTXGL2KPANCNFSM6AAAAAAUBYBDQU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
sudo : ss : command not found - using Advanced SSH & Web Terminal Addon |
Hello,
What operating system are you using? What the below command in CLI shows:
cat /etc/os-release
You can eventually use the below command in CLI - command line (terminal)
instead of sudo ss -tulpn | grep " 53"
sudo netstat -tulpn | grep " 53"
Adrian Ambroziak
…On Tue, May 16, 2023 at 11:55 AM reddog-42 ***@***.***> wrote:
sudo : ss : command not found - using Advanced SSH & Web Terminal Addon
—
Reply to this email directly, view it on GitHub
<#385 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFULAOVJGESXCITN223ROFLXGNFHZANCNFSM6AAAAAAUBYBDQU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
running Home Assistant OS on RPi 4 ~ $ cat /etc/os-release ~ sudo netstat -tulpn | grep "udp" |
Not grep "udp" but grep " 53" You want to check what is listening on port
53 not to list all services that are listening on udp.
wt., 16 maj 2023, 14:50 użytkownik reddog-42 ***@***.***>
napisał:
… running Home Assistant OS on RPi 4
~ $ cat /etc/os-release
Name="Alpine Linux"
ID=alpine
VERSION_ID=3.17.3
PRETTY_NAME="Alpine Linux v3.17"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://github.alpinelinux.org/alpine/aports/-/issues"
~ sudo netstat -tulpn | grep " 53" ( no output )
nothing on port 53
~ sudo netstat -tulpn | grep "udp"
udp 0 0 0.0.0.0:46277 0.0.0.0:* -
udp 0 0 10.0.0.38:5353 0.0.0.0:* -
udp 0 0 172.30.32.1:5353 0.0.0.0:* -
udp 0 0 0.0.0.0:5353 0.0.0.0:* -
udp 0 0 0.0.0.0:5353 0.0.0.0:* -
udp 0 0 0.0.0.0:5353 0.0.0.0:* -
udp 0 0 0.0.0.0:1900 0.0.0.0:* -
udp 0 0 0.0.0.0:1900 0.0.0.0:* -
udp 0 0 10.0.0.255:137 0.0.0.0:* -
udp 0 0 10.0.0.38:137 0.0.0.0:* -
udp 0 0 0.0.0.0:137 0.0.0.0:* -
udp 0 0 10.0.0.255:138 0.0.0.0:* -
udp 0 0 10.0.0.38:138 0.0.0.0:* -
udp 0 0 0.0.0.0:138 0.0.0.0:* -
udp 0 0 0.0.0.0:37154 0.0.0.0:* -
udp 0 0 0.0.0.0:45390 0.0.0.0:* -
udp6 0 0 :::50251 :::* -
udp6 0 0 :::5353 :::* -
udp6 0 0 :::5353 :::* -
udp6 0 0 fd51:2d59:96c1:1:::5353 :::* -
udp6 0 0 fd51:2d59:96c1:1:::5353 :::* -
udp6 0 0 :::5355 :::* -
udp6 0 0 :::36244 :::* -
udp6 0 0 :::1900 :::* -
udp6 0 0 :::1900 :::* -
udp6 0 0 :::1900 :::* -
udp6 0 0 fe80::61a4:5e11:139:546 :::* -
udp6 0 0 fe80::f268:cc28:828:546 :::* -
~
—
Reply to this email directly, view it on GitHub
<#385 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFULAOWFGKCBVSAJZRXYJKLXGNZX3ANCNFSM6AAAAAAUBYBDQU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Sorry, |
Solved. Thanks for your help. |
That is strange because Adguard home says that cannot bind port 53, because
it is already taken. I suppose that it is taken by some mdns or something
like that.
wt., 16 maj 2023, 23:48 użytkownik reddog-42 ***@***.***>
napisał:
… Sorry,
As above, grep " 53" gave no output. There isn't anything active on port
53.
—
Reply to this email directly, view it on GitHub
<#385 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFULAORN6VDYXIZHNXRQ3DDXGPY2FANCNFSM6AAAAAAUBYBDQU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
It was working till the change with the IPv6 that has been made by the
developer. I am glad you solved it.
śr., 17 maj 2023, 02:00 użytkownik reddog-42 ***@***.***>
napisał:
… Solved. Thanks for your help.
My router was giving the same ipv4 address (dhcp) to the wlan0 interface
as the static eth0 interface, so seems adguard was trying to listen twice
on the same address.
I updated wlan0 to a different static address and adguard now starts
happily.
Not sure why it has been working for the last year or so.
—
Reply to this email directly, view it on GitHub
<#385 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFULAOVE7GJYTDDWVZ23YF3XGQIJRANCNFSM6AAAAAAUBYBDQU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
There hasn't been any activity on this issue recently, so we clean up some of the older and inactive issues. |
😢 user@NanoPi:~# docker logs adguard -f
2023/06/29 19:15:37.899325 [info] AdGuard Home, version v0.108.0-a.586+2069eddf
2023/06/29 19:15:37.899743 [info] AdGuard Home updates are disabled
2023/06/29 19:15:37.918536 [info] tls: using default ciphers
2023/06/29 19:15:37.932912 [info] safesearch default: reset 194 rules
2023/06/29 19:15:38.069059 [info] Initializing auth module: /opt/adguardhome/work/data/sessions.db
2023/06/29 19:15:38.069708 [info] auth: initialized. users:1 sessions:5
2023/06/29 19:15:38.070767 [info] tls: number of certs: 3
2023/06/29 19:15:38.070905 [info] tls: got an intermediate cert
2023/06/29 19:15:38.070963 [info] tls: got an intermediate cert
2023/06/29 19:15:38.195787 [info] web: initializing
2023/06/29 19:15:38.759103 [info] dnsproxy: cache: enabled, size 4096 b
2023/06/29 19:15:38.759170 [info] dnsproxy: max goroutines is set to 300
2023/06/29 19:15:38.760965 [info] AdGuard Home is available at the following addresses:
2023/06/29 19:15:38.761555 [info] go to https://MY_DOMAIN:443
2023/06/29 19:15:38.762074 [info] go to http://127.0.0.1:80
2023/06/29 19:15:38.762202 [info] go to http://172.20.0.2:80
2023/06/29 19:15:47.577103 [info] dnsproxy: starting dns proxy server
2023/06/29 19:15:47.577308 [info] Ratelimit is enabled and set to 20 rps
2023/06/29 19:15:47.577335 [info] The server is configured to refuse ANY requests
2023/06/29 19:15:47.577352 [info] dnsproxy: cache: enabled, size 16777216 b
2023/06/29 19:15:47.577384 [info] dnsproxy: max goroutines is set to 300
2023/06/29 19:15:47.577463 [info] dnsproxy: creating udp server socket XXX.XXX.XXX.XXX:53
2023/06/29 19:15:47.676151 [fatal] couldn't start forwarding DNS server: starting listeners: listening on udp addr XXX.XXX.XXX.XXX:53: listening to udp socket: listen udp XXX.XXX.XXX.XXX:53: bind: cannot assign requested address user@NanoPi:~# netstat -tulpn | grep ":53 "
user@NanoPi:~# user@NanoPi:~# cat /etc/sysctl.conf
net.ipv6.conf.lo.disable_ipv6 = 0 Link docker-compose.yaml |
I still face exactly the same issue - why close it? |
The solution is to re-enable IPv6 support on the box. |
i had ipv6 enabled and i still have this issue |
Problem/Motivation
After upgrading to new versione I got this error
[fatal] couldn't start forwarding DNS server: listening to udp socket: listen udp 127.0.0.1:53: bind: address already in use
Supervised on Debian 11 Kernel 5.10.158-2
Supervisor 2022.12.1
Home Assistant 2023.1.6
I tried to restore to previous version and the addon is function again, so I upgraded again and got same error.
Steps to reproduce
Upgrading to latest version
The text was updated successfully, but these errors were encountered: