Systemd-resolved.service

So another day, another stink bomb hidden in a supervised install.
image

Now everything seems to be working and there are no unexpected errors in Supervisor. I have never touched systemd-resolved.service. Do I need to enable this service or is it something I can ignore?

Just as an aside in recent months, any docker or supervisor update has forced me to reinstall HA but with a recent supervisor/dns update, everything is working perfectly again.

The docs aren’t all that helpful. Systemd-Resolved - Home Assistant
I wonder if I should enable it and start it and wonder why this happened anyway?

david@debian:~$ sudo systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
             https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients

For what it’s worth, I tried enabling it and then wasn’t able to access HA after that. So I disabled it again and just ignored the error, just like my ‘unsupported software detected’ message :sweat_smile:

Edit: after reading the other comments I realized I had to start it too, and only just enabled it lol.

I enabled and started it but still see the error. Running status says it’s running. It also says

david@debian:~$ sudo systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2022-03-11 13:32:01 AEDT; 5min ago
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
             https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
   Main PID: 138964 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 9004)
     Memory: 4.7M
        CPU: 1.044s
     CGroup: /system.slice/systemd-resolved.service
             └─138964 /lib/systemd/systemd-resolved

Mar 11 13:32:01 debian systemd[1]: Starting Network Name Resolution...
Mar 11 13:32:01 debian systemd-resolved[138964]: Positive Trust Anchors:
Mar 11 13:32:01 debian systemd-resolved[138964]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Mar 11 13:32:01 debian systemd-resolved[138964]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18>
Mar 11 13:32:01 debian systemd-resolved[138964]: Using system hostname 'debian'.
Mar 11 13:32:01 debian systemd[1]: Started Network Name Resolution.
Mar 11 13:32:01 debian systemd-resolved[138964]: mDNS-IPv4: There appears to be another mDNS responder running, or previously syste>
Mar 11 13:32:01 debian systemd-resolved[138964]: mDNS-IPv6: There appears to be another mDNS responder running, or previously syste>

No idea what is going on. Maybe I should just disable it again and add it to the list of stuff HA thinks is broken but isn’t

I had same problem on four separate supervised installs. Enabled, started, then rebooted. Now supported and healthy again. No idea how/why this broke.

1 Like

Are you running avahi? That’ll conflict.

My systemd-resolved service had stopped.

systemctl status systemd-resolved

I started the service again and the supervisor error went away

systemctl start systemd-resolved
2 Likes

Even though I had reloaded supervisor it didn’t clear systemd-resolved error until I restarted so now I am back to just ignored job conditions (because I set it to ignore unhealthy) and Unsupported software detected because I have the temerity to run other non HA containers. I’m eagerly awaiting the next unscheduled bastardry with great anticipation.

1 Like
david@debian:~$ sudo systemctl status avahi
Unit avahi.service could not be found.

Same here. Enabled it, rebooted, fixed. It was never enabled before, but everything keeps working.

seems like no one else had noticed this was happening until I pointed it out?

turns out I’m an idiot and avahi-daemon WAS running which is why I had mDNS… disabled that now and rebooted and I have


david@debian:~$ sudo systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2022-03-11 15:47:27 AEDT; 3min 29s ago
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
             https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
   Main PID: 473 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 9004)
     Memory: 9.2M
        CPU: 532ms
     CGroup: /system.slice/systemd-resolved.service
             └─473 /lib/systemd/systemd-resolved

Mar 11 15:47:26 debian systemd[1]: Starting Network Name Resolution...
Mar 11 15:47:27 debian systemd-resolved[473]: Positive Trust Anchors:
Mar 11 15:47:27 debian systemd-resolved[473]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Mar 11 15:47:27 debian systemd-resolved[473]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.17>
Mar 11 15:47:27 debian systemd-resolved[473]: Using system hostname 'debian'.
Mar 11 15:47:27 debian systemd[1]: Started Network Name Resolution.
1 Like

So I see from here Releases · home-assistant/supervised-installer · GitHub that they removed the previous requirement for avahi-daemon in version 1.02 released 3 Nov 2021. It would have been nice if they informed us of this change then. But it appears only now are they telling up there is an issue if systemd-resolvd isn’t installed.
I suppose this is probably the only way they can warn us of an issue in a current installation however I have reinstalled supervised 10’s of times since November as HA would not start/come back after a reboot or a docker update or a supervisor update. I never saw a warning about an issue (when I re-ran the installation package) with this till yesterday. It might be a good idea when a requirement changes or there is a breaking change like this to issue a blog post? Seems like a lot of very competent experienced users didn’t know they had this issue either until I posted this yesterday.

3 Likes

As long as there is no problem, there is little need to go see if your installation is still supported. It is only if I read something on the forum that alarms me that I go see if I’m affected.

It’s always better to pre-emptively look for problems before your system dies ‘without warning’

Yes, it reminds me to look at that page every month before I install the beta. It’s on my to-do list.

In this case I believe it’s a supervisor changed and that auto upgrades on it’s own so you don’t get that luxury.

I know supervisor auto-updates, but I just intent to look at the supervisor tab each time before or after the update, so I don’t forget to regularly watch that page :slight_smile: Otherwise I will forget.

Hello @DavidFW1960 and @mattdm

Had the same issue here (and i need avahi for room-assistant).
So instead of disabling service, i just add

DNSStubListener=no

into /etc/systemd/resolved.conf

So far, so good


image

4 Likes

So, I am also suddenly unsupported for this same reason. I have tried the above and it has not fixed my condition.

“sudo systemctl status avahi” results in “Unit avahi.services could not be found”, so not running. I did go ahead and disable the DNSStubListener and rebooted the host with no change.

This is the only complaint in my supervisor log regarding d-bus.

22-03-16 09:57:00 WARNING (MainThread) [supervisor.dbus.manager] Can't load dbus interface de.pengutronix.rauc: The name de.pengutronix.rauc was not provided by any .service files

I do have a line of negative trust anchors when I check with “systemctl status systemd-resolved”. I am unable to copy them here because I do not have ssh access into the base OS, only console.

I am running Debian 5.10.103-1

I finally got mine to resolve by flushing cache and rebooting the system.

Check systemctl status avahi-daemon