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 
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
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
I did type that, just mistyped since I don’t have ssh into my base os and have to type everything from that window.
My debian 11 amd64 system runs supervised. Both avahi-daemon and systemd-resolved are running, with no discernable problem.
Nick did you leave MDNS running as well? I disabled avahi-daemon and everything is working.
What is the service name?
Its enabled with avahi-daemon unless you edit the options as I did above. If you do a systemctl status avahi-daemon you can see in the output