[Bug] Service Fails to Start

zero77 commented 7 months ago

Prerequisites

[X] I have checked the Wiki and Discussions and found no answer
[X] I have searched other issues and found no duplicates
[X] I want to report a bug and not ask a question or ask for help
[X] I have set up AdGuard Home correctly and configured clients to use it. (Use the Discussions for help with installing and configuring clients.)

Platform (OS and CPU architecture)

Linux, AMD64 (aka x86_64)

Installation

Snapcraft

Setup

Other (please mention in the description)

AdGuard Home version

v0.108.0-a.861+14c6be3b

Action

On a reboot or service restart the AdGuard Home snap service fails to start and only shows the two errors below. After doing some more investigating i found that if i add another dns server to the resolv file and try to start the service again it works.

So it looks like AdGuard Home will not start if it's the only dns server configured in resolv and the upstream or fall back dns settings don't make a difference.

I am using Debian and have the below dns settings configured:

/etc/resolv.conf nameserver 127.0.0.1

The errors below are the only errors i have found: /var/log/syslog adguard-home.adguard-home[170191]: [error] querylog: closing: flushing log buffer: nothing to write to a file adguard-home.adguard-home[170191]: [fatal] dnsServer.Prepare: setting up resolvers: creating local resolvers: validating general upstreams: no upstream specified

Expected result

The AdGuard Home snap service should start automatically after a reboot or service restart , even if it's the only dns server configured on the host in resolv.

Actual result

The AdGuard Home snap service fails to start when it is the only dns server configured on the host in resolv.

Additional information and/or screenshots

No response

EugeneOne1 commented 7 months ago

@zero77, hello and thanks for the report. It seems AdGuard Home can't find any appropriate resolvers for private PTR queries, since it probably listens to 127.0.0.1 and filters it out to avoid recursion. If the assumption is correct, you'd probably want to uncheck the "Use private reverse DNS resolvers" checkbox (set dns.use_private_ptr_resolvers to false in YAML configuration file), since it will result into NXDOMAIN answers for all private PTR queries as well. If this worked for you?

zero77 commented 7 months ago

@EugeneOne1 Thanks for the quick response, i have changed use_private_ptr_resolvers to false and i think its working but i will watch it to make sure this has fixed the problem.

Is there a way this could default to false if 127.0.0.1 is being used.

EugeneOne1 commented 7 months ago

@zero77, hello again. We've pushed the latest edge build that should automatically disable the PTR resolvers usage along with the appropriate warning message in log. Could you please check it out?

zero77 commented 7 months ago

@EugeneOne1 Thanks for your help, i have updated to v0.108.0-a.865+ee014418 but cannot see any changes as i already made the change you suggested. I also cannot see any warnings with grep adguard /var/log/syslog only [info] but the fix you suggested has worked.

EugeneOne1 commented 7 months ago

@zero77, well, in order to meet the message, you have to set the dns.use_private_ptr_resolvers back to true. However, you'd probably want to keep it disabled afterwards, since you don't use it anyway. The message itself should be logged at [info] level with a "WARNING: ..." prefix.

agross commented 7 months ago

Hello @EugeneOne1,

I have this in my config and I want to use these private DNS upstreams despite them running on 127.0.0.1:

  use_private_ptr_resolvers: true
  local_ptr_upstreams:
    - '# Resolve IPv4 PTR using dnsmasq...'
    - '[/in-addr.arpa/]127.0.0.1:53532'
    - '# ...and IPv6 PTR using systemd-resolved which supports NDP to resolve link-local addresses.'
    - '[/ip6.arpa/]127.0.0.1:53531'

The adguard/adguardhome:latest (3bd2fdc8bdc9) and adguard/adguardhome:edge (90ca18c8baca) images still fail with this message.

EugeneOne1 commented 7 months ago

@agross, hello. It seems you haven't specified the default (not domain-specific) upstream servers. Since those upstreams handle only the PTR requests for private IP addresses, i.e. only *.in-addr.arpa and *.ip6.arpa, I suppose you may simply remove one of the specifications, e.g.:

local_ptr_upstreams:
  - '# Resolve IPv4 PTR using dnsmasq...'
  - '127.0.0.1:53532'
  - '# ...and IPv6 PTR using systemd-resolved which supports NDP to resolve link-local addresses.'
  - '[/ip6.arpa/]127.0.0.1:53531'

agross commented 7 months ago

@EugeneOne1 Thanks for the prompt response! Yes, removing [/in-addr.arpa/] solves the issues. The latest image now starts up. Thanks!

EugeneOne1 commented 7 months ago

@agross, I've actually tried this configuration with several versions, including the one before the commit that caused this problem, and it didn't work. So out of curiosity, has this configuration ever worked? And if it did, do you remember the last such version?

agross commented 7 months ago

@EugeneOne1 Yes, it worked until yesterday when I upgraded the image. The version I used before was using config schema version 27 (or at least it was able to understand it). It's a bit of a guess from yesterday's shell logs, but this is an old version:

adguard/adguardhome@sha256:efe08a321f2328e72e2d173818fb08ce25a2af5fbb94ad80cf4ddb04f79a95cc

Its first lines of the image's output match the log output stored in the system journal from e.g. March 12: AdGuard Home, version v0.107.40

Here's the config for you to try (old schema):

```yaml http: pprof: port: 6060 enabled: false address: 0.0.0.0:30000 session_ttl: 720h auth_attempts: 5 block_auth_min: 15 http_proxy: "" language: "" theme: auto dns: bind_hosts: - 0.0.0.0 port: 53 anonymize_client_ip: false ratelimit: 0 ratelimit_whitelist: [] refuse_any: true upstream_dns: - '# dnsmasq.' - 127.0.0.1:53532 - '[/ogd.therightstuff.de/]172.16.1.3' upstream_dns_file: "" bootstrap_dns: - 1.1.1.1 - 1.0.0.1 - 9.9.9.10 - 149.112.112.10 - 2620:fe::10 - 2620:fe::fe:10 fallback_dns: [] all_servers: false fastest_addr: false fastest_timeout: 1s allowed_clients: [] disallowed_clients: [] blocked_hosts: - version.bind - id.server - hostname.bind trusted_proxies: - 127.0.0.0/8 - ::1/128 cache_size: 0 cache_ttl_min: 0 cache_ttl_max: 0 cache_optimistic: false bogus_nxdomain: [] aaaa_disabled: false enable_dnssec: false edns_client_subnet: custom_ip: "" enabled: false use_custom: false max_goroutines: 300 handle_ddr: true ipset: [] ipset_file: "" bootstrap_prefer_ipv6: false upstream_timeout: 10s private_networks: [] use_private_ptr_resolvers: true local_ptr_upstreams: - '# Resolve IPv4 PTR using dnsmasq...' - '[/in-addr.arpa/]127.0.0.1:53532' - '# ...and IPv6 PTR using systemd-resolved which supports NDP to resolve link-local addresses.' - '[/ip6.arpa/]127.0.0.1:53531' use_dns64: false dns64_prefixes: [] serve_http3: false use_http3_upstreams: false tls: enabled: false server_name: "" force_https: false port_https: 443 port_dns_over_tls: 853 port_dns_over_quic: 784 port_dnscrypt: 0 dnscrypt_config_file: "" allow_unencrypted_doh: false certificate_chain: "" private_key: "" certificate_path: "" private_key_path: "" strict_sni_check: false querylog: ignored: [] interval: 24h size_memory: 1000 enabled: true file_enabled: true statistics: ignored: [] interval: 2160h enabled: true filters: - enabled: true url: https://adguardteam.github.io/AdGuardSDNSFilter/Filters/filter.txt name: AdGuard DNS filter id: 1 - enabled: true url: https://adaway.org/hosts.txt name: AdAway Default Blocklist id: 2 - enabled: true url: https://easylist.to/easylistgermany/easylistgermany.txt name: EasyList Germany id: 1638723473 - enabled: true url: https://easylist.to/easylist/easylist.txt name: EasyList id: 1638723474 whitelist_filters: [] user_rules: - '@@||localhost^$important' dhcp: enabled: false interface_name: "" local_domain_name: lan dhcpv4: gateway_ip: "" subnet_mask: "" range_start: "" range_end: "" lease_duration: 86400 icmp_timeout_msec: 1000 options: [] dhcpv6: range_start: "" lease_duration: 86400 ra_slaac_only: false ra_allow_slaac: false filtering: blocking_ipv4: "" blocking_ipv6: "" blocked_services: schedule: time_zone: Local ids: [] protection_disabled_until: null safe_search: enabled: false bing: true duckduckgo: true google: true pixabay: true yandex: true youtube: true blocking_mode: nxdomain parental_block_host: family-block.dns.adguard.com safebrowsing_block_host: standard-block.dns.adguard.com rewrites: [] safebrowsing_cache_size: 1048576 safesearch_cache_size: 1048576 parental_cache_size: 1048576 cache_time: 30 filters_update_interval: 12 blocked_response_ttl: 10 filtering_enabled: true parental_enabled: false safebrowsing_enabled: false protection_enabled: true clients: runtime_sources: whois: true arp: true rdns: true dhcp: true hosts: false persistent: [] log: file: "" max_backups: 0 max_size: 100 max_age: 3 compress: false local_time: false verbose: false os: group: "" user: "" rlimit_nofile: 0 schema_version: 27 ```

$ docker run --rm -v /dir/with/config/above:/opt/adguardhome/conf adguard/adguardhome@sha256:efe08a321f2328e72e2d173818fb08ce25a2af5fbb94ad80cf4ddb04f79a95cc

2024/03/26 08:10:31.657797 [info] AdGuard Home, version v0.107.40
...
2024/03/26 08:10:31.665521 [info] dnsproxy: max goroutines is set to 300
2024/03/26 08:10:31.665526 [info] dnsproxy: creating udp server socket 0.0.0.0:53
...

versus:

$ docker run --rm -v /dir/with/config/above:/opt/adguardhome/conf adguard/adguardhome:latest

2024/03/26 08:11:12.110836 [info] AdGuard Home, version v0.107.46
2024/03/26 08:11:12.111399 [info] Upgrade yaml: 27 to 28
...
2024/03/26 08:11:12.117672 [info] dnsproxy: max goroutines is set to 300
2024/03/26 08:11:12.119139 [error] querylog: closing: flushing log buffer: nothing to write to a file
2024/03/26 08:11:12.119146 [fatal] dnsServer.Prepare: setting up resolvers: creating local resolvers: validating general upstreams: no default upstreams specified

EugeneOne1 commented 7 months ago

@agross, thank you for your thorough answer, this is really helpful. We'll investigate it since the behavior isn't really intended and may be caused by another bug.

AdguardTeam / AdGuardHome