AdguardTeam / AdGuardHome

Network-wide ads & trackers blocking DNS server
https://adguard.com/adguard-home/overview.html
GNU General Public License v3.0
25.55k stars 1.83k forks source link

Adguard not starting on reboot with tailscaled installed. #7057

Closed stepanovdg closed 5 months ago

stepanovdg commented 5 months ago

Prerequisites

The problem

I am running adguard home on opnsense with tailscaled installed. I have multiple ips specifying on which adguard home will work (53 port). One of them is tailscale ip 100.x.x.x .

2024/05/31 00:15:04.880859 [info] dnsproxy: creating udp server socket 100.x.x.x:53
2024/05/31 00:15:04.891119 [error] querylog: closing: flushing log buffer: nothing to write to a file
2024/05/31 00:15:04.891227 [fatal] couldn't start forwarding DNS server: starting listeners: listening on udp addr 100.x.x.x:53: listening to udp socket: listen udp 100.x.x.x:53: bind: can't assign requested address

When machine is rebooted adguardhome is starting before tailscaled and fail to bind to that ip. So just fail. And there is no dns - until I start adguard service later manually (later working fine).

Proposed solution

Not sure ( But maybe adguardhome can be started after all networking is up. Or can try several retries with some timeout.

Alternatives considered and additional information

Tried to use require tailscaled in (.../rc.d/adguardhome) but looks like need some later phase.

#!/bin/sh
# PROVIDE: adguardhome 
# REQUIRE: tailscaled
Cebeerre commented 5 months ago

I'd suggest to take a look here: https://docs.freebsd.org/en/articles/rc-scripting/#rcng-hookup

Specifically, this:

Keep in mind that putting a service name in the REQUIRE: line does not guarantee that the service will actually be running by the time our script starts. The required service may fail to start or just be disabled in rc.conf(5). Obviously, rcorder(8) cannot track such details, and rc(8) will not do that either. Consequently, the application started by our script should be able to cope with any required services being unavailable. In certain cases, we can help it as discussed below

I'd say that coping with all the specifics of custom scenarios would be quite a challenge to manage inside AGH itself, so as per the FreeBSD wiki I'd fine tune the rc.d script to make some validations and wait till my custom scenario is up and running (I've myself something similar in OpenWRT). Having said that, I'll let @ainar-g to share what they think from the development team.

stepanovdg commented 5 months ago

Just couple more info. I tried to look the order of loading services and at tailscaled github noticed there are several issues saying that actual interface ready for binding appear later (after service is started). And as workaround they suggest create additional service that listen for taiscaled and then in loop check if interface is ready. And to have dependency on this wrapper service instead. Hopefully will try today that workaround.

stepanovdg commented 5 months ago

So next rc helped.

#!/bin/sh

# PROVIDE: tailscale_ip
# REQUIRE: tailscaled
# KEYWORD: shutdown
#

. /etc/rc.subr

name=tailscale_ip
rcvar=tailscaled_enable

load_rc_config tailscaled
load_rc_config $name

: ${tailscaled_enable:="NO"}
: ${tailscaled_tun_dev:="tailscale0"}

start_cmd="tailscale_wait_for_ip"

tailscale_wait_for_ip() {
    while ! ifconfig ${tailscaled_tun_dev} | grep -q 'inet '; do
        sleep 10
    done
}

run_rc_command "$1"

and in .../rc.d/adguardhome

#!/bin/sh

# PROVIDE: adguardhome
# REQUIRE: tailscale_ip
# KEYWORD: shutdown
...
Cebeerre commented 5 months ago

Glad you managed to fix it. I'll proceed to close the issue.