HAOS mDNS failed last night

Configuration
1

Last night about 21:20 local time HA became unresponsive. Turns out it wasn’t advertising it’s hostname any more – or the expected host name. But, that looks like that was a result of a supervisor update (that I didn’t do). The host got very busy with DNS issues and my CPU (and memory) spiked.

  • Core 2025.12.5
  • Supervisor 2026.01.0
  • Operating System 16.3
  • Running in Proxmox 9.1.4

My hostname is configured as “havm” and on the HAOS host /etc/hostname shows “havm”.
The host’s IP is 192.168.0.70.

I have restarted the HAOS VM multiple times. The mDNS name comes back briefly, but then no longer works. I wonder if it’s somehow related to Apparmor update.

Caveat: I don’t fully understand if it’s HAOS (systemd-resolved) that is publishing its name via mDNS, or core.

Any debugging tips? Try and rollback Supervisor, although I’m not sure that’s where the issue is.

The logs are long, so collapsed them below.

Last night in the supervisor logs it looks like it was updated and shutdown and watchdog restarted it. (I was not on the machine at that time) 
2026-01-07 20:54:01.652 INFO (MainThread) [supervisor.homeassistant.api] Updated Home Assistant API token
2026-01-07 21:21:35.564 INFO (MainThread) [supervisor.updater] Fetching update data from https://version.home-assistant.io/stable.json
2026-01-07 21:21:35.677 INFO (MainThread) [supervisor.misc.tasks] Found new Supervisor version 2026.01.0, updating
2026-01-07 21:21:35.678 INFO (MainThread) [supervisor.supervisor] Fetching AppArmor profile https://version.home-assistant.io/apparmor_stable.txt
2026-01-07 21:21:35.699 INFO (MainThread) [supervisor.host.apparmor] Adding/updating AppArmor profile: hassio-supervisor
2026-01-07 21:21:35.768 INFO (MainThread) [supervisor.supervisor] Update Supervisor to version 2026.01.0
2026-01-07 21:21:35.769 INFO (MainThread) [supervisor.docker.interface] Downloading docker image ghcr.io/home-assistant/amd64-hassio-supervisor with tag 2026.01.0.
2026-01-07 21:21:41.934 INFO (MainThread) [supervisor.misc.scheduler] Shutting down scheduled tasks
2026-01-07 21:21:41.934 INFO (MainThread) [supervisor.docker.monitor] Stopped docker events monitor
2026-01-07 21:21:41.935 INFO (MainThread) [supervisor.api] Stopping API on 172.30.32.2
2026-01-07 21:21:41.936 INFO (MainThread) [supervisor.hardware.monitor] Stopped Supervisor hardware monitor
2026-01-07 21:21:41.938 INFO (MainThread) [supervisor.dbus.manager] Closed conection to system D-Bus.
2026-01-07 21:21:41.941 WARNING (MainThread) [supervisor.homeassistant.websocket] Connection is closed
2026-01-07 21:21:41.942 INFO (MainThread) [supervisor.core] Supervisor is down - 0
2026-01-07 21:21:41.943 INFO (MainThread) [__main__] Closing Supervisor
[05:21:42] WARNING: Halt Supervisor
[05:21:42] INFO: Supervisor restart after closing
s6-rc: info: service legacy-services: stopping
[05:21:42] INFO: Watchdog restart after closing
At that same time, the host logs went crazy reporting dns errors.

I’m GMT-8, so 21:30 for me is 05:30 in the host logs.

2026-01-08 05:21:50.854 havm systemd[1]: Starting HassOS supervisor...
2026-01-08 05:21:50.886 havm systemd[1]: Started HassOS supervisor.
2026-01-08 05:21:50.938 havm hassos-supervisor[423898]: [INFO] Supervisor image has been updated, destroying previous container...
2026-01-08 05:21:50.965 havm hassos-supervisor[423918]: hassio_supervisor
2026-01-08 05:21:50.968 havm hassos-supervisor[423898]: [INFO] Creating a new Supervisor container...
2026-01-08 05:21:50.995 havm systemd[1]: var-lib-docker-overlay2-04420648b2d88754d627c30aa7512c1841fa63d51eef6173f8a71a7951df4c06\x2dinit-merged.mount: Deactivated successfully.
2026-01-08 05:21:50.995 havm systemd[1]: mnt-data-docker-overlay2-04420648b2d88754d627c30aa7512c1841fa63d51eef6173f8a71a7951df4c06\x2dinit-merged.mount: Deactivated successfully.
2026-01-08 05:21:51.008 havm hassos-supervisor[423926]: af211a07772504ab9449bb05d71c97a61ff44eea42ee91b16fae75d015141a8a
2026-01-08 05:21:51.011 havm hassos-supervisor[423898]: [INFO] Starting the Supervisor...
2026-01-08 05:21:51.075 havm systemd[1]: Started libcontainer container af211a07772504ab9449bb05d71c97a61ff44eea42ee91b16fae75d015141a8a.

(trimmed)

Then this goes on for for a very long time:

$ fgrep -c 'changing published hostnam' host_2026-01-08T17-46-52.103Z.log
17060

2026-01-08 05:21:53.062 havm os-agent[398]: INFO: 2026/01/07 21:21:53 apparmor.go:53: Load profile '/mnt/data/supervisor/apparmor/hassio-supervisor':
2026-01-08 05:21:53.114 havm systemd-resolved[385]: Detected conflict on havm\032\0919f61b67342f6477fabc23db203939358\093._workstation._tcp.local IN SRV 0 0 0 havm.local
2026-01-08 05:21:53.114 havm systemd-resolved[385]: Detected conflict on havm\032\0919f61b67342f6477fabc23db203939358\093._workstation._tcp.local IN TXT ""
2026-01-08 05:21:53.114 havm systemd-resolved[385]: Detected conflict on havm.local IN A 192.168.0.70
2026-01-08 05:21:53.114 havm systemd-resolved[385]: Hostname conflict, changing published hostname from 'havm' to 'havm3'.
2026-01-08 05:21:53.194 havm systemd-resolved[385]: Detected conflict on havm3\032\0919f61b67342f6477fabc23db203939358\093._workstation._tcp.local IN TXT ""
2026-01-08 05:21:53.194 havm systemd-resolved[385]: Detected conflict on havm3\032\0919f61b67342f6477fabc23db203939358\093._workstation._tcp.local IN SRV 0 0 0 havm3.local
2026-01-08 05:21:53.194 havm systemd-resolved[385]: Detected conflict on havm3.local IN A 192.168.0.70
2026-01-08 05:21:53.194 havm systemd-resolved[385]: Hostname conflict, changing published hostname from 'havm3' to 'havm13'.
2026-01-08 05:21:53.361 havm systemd-resolved[385]: Detected conflict on havm13\032\0919f61b67342f6477fabc23db203939358\093._workstation._tcp.local IN TXT ""
2026-01-08 05:21:53.361 havm systemd-resolved[385]: Detected conflict on havm13\032\0919f61b67342f6477fabc23db203939358\093._workstation._tcp.local IN SRV 0 0 0 havm13.local
2026-01-08 05:21:53.361 havm systemd-resolved[385]: Detected conflict on havm13.local IN A 192.168.0.70
2026-01-08 05:21:53.361 havm systemd-resolved[385]: Hostname conflict, changing published hostname from 'havm13' to 'havm20'.
And now HAOS is reporting its name as b9f32a5e57c5481790f14807573e257c.local

Note that b9f32a5e57c5481790f14807573e257c is the core’s uuid:

➜  .storage jq . core.uuid
{
  "version": 1,
  "minor_version": 1,
  "key": "core.uuid",
  "data": {
    "uuid": "b9f32a5e57c5481790f14807573e257c"
  }
}

$ avahi-browse -r  _home-assistant._tcp
+ wlp3s0 IPv6 Home                                          _home-assistant._tcp local
+ wlp3s0 IPv4 Home                                          _home-assistant._tcp local
+   eth0 IPv6 Home                                          _home-assistant._tcp local
+   eth0 IPv4 Home                                          _home-assistant._tcp local
= wlp3s0 IPv6 Home                                          _home-assistant._tcp local
   hostname = [b9f32a5e57c5481790f14807573e257c.local]
   address = [192.168.0.70]
   port = [8123]
   txt = ["requires_api_password=True" "base_url=http://192.168.0.70:8123" "internal_url=http://192.168.0.70:8123" "external_url=" "version=2025.12.5" "uuid=b9f32a5e57c5481790f14807573e257c" "location_name=Home"]

What’s this look like to you?

2

Ugh, for “fun” I just changed the HA hostname (via the UI) to “haother” and now the host is going crazy again:

2026-01-08 18:20:39.523 haother systemd-resolved[382]: Detected conflict on haother999\032\0919f61b67342f6477fabc23db203939358\09325._workstation._tcp.local IN SRV 0 0 0 haother999.local
2026-01-08 18:20:39.523 haother systemd-resolved[382]: Detected conflict on haother999\032\0919f61b67342f6477fabc23db203939358\09325._workstation._tcp.local IN TXT ""
2026-01-08 18:20:39.523 haother systemd-resolved[382]: Detected conflict on haother999.local IN A 192.168.0.70
2026-01-08 18:20:39.523 haother systemd-resolved[382]: Hostname conflict, changing published hostname from 'haother999' to 'haother1009'.
2026-01-08 18:20:39.580 haother systemd-resolved[382]: Detected conflict on haother1009\032\0919f61b67342f6477fabc23db203939358\09325._workstation._tcp.local IN SRV 0 0 0 haother1009.local
2026-01-08 18:20:39.580 haother systemd-resolved[382]: Detected conflict on haother1009\032\0919f61b67342f6477fabc23db203939358\09325._workstation._tcp.local IN TXT ""
2026-01-08 18:20:39.680 haother systemd-resolved[382]: Detected conflict on haother1009\032\0919f61b67342f6477fabc23db203939358\09325._workstation._tcp.local IN TXT ""
2026-01-08 18:20:39.680 haother systemd-resolved[382]: Detected conflict on haother1009\032\0919f61b67342f6477fabc23db203939358\09325._workstation._tcp.local IN SRV 0 0 0 haother1009.local
3

I saw this post and i got rather curious, so i used DNS-SD on macOS and mine is also some really bizarre hostname. (2026.0)

But for me, homeassistant.local works just fine still.

Home._home-assistant._tcp.local. can be reached at 73eaaeea319d408490d57912224be891.local.:8123
4

So much for downgrading.

There is a 2025.12.3 version, but:

➜  ~ ha supervisor update --version=2025.12.3
Processing... Done.

Error: No supervisor update available - 2026.01.0

Would I have to do it in docker? Stop the container and pull that tag?

5

Do you not have a backup to restore from? I think that’s the easiest way. Or is that not how it works? I always assumed backups could downgrade.

6

Also, i see you are running Supervisor 2026 but not Core 2026, have you considered updating Core to match?

7

Yes, I did. I’ll give that a try if cannot figure it out. I have a backup, too.

Obviously, I want to fix this, but I’d really like to understand what happened.

That, and how the mDNS stuff works in HA. e.g. what happens when you update the hostname in the UI? I assume Supervisor somehow tells the host to update networking. Or is one of the containers using python-zeroconf to announce the name?

1 Like
8

BTW, the backup is just the data. I’d need to re-install. I have a Proxmox template of a older fresh HA install, but not quite sure why the same thing wouldn’t happen again.

I might try the docker pull of the older supervisor.

Anyone else have their Supervisor updated?

1 Like
9

Ah, I’m not alone:

1 Like
10

Ah oh, good to know. I must be thinking of addon updates where it asks to make a backup for rollback purposes.

11

The issue looks like due to you changing the setting directly in the OS, when it is in fact managed by HAOS’s GUI under settings → network

HAOS is not meant to be tampered with.

12

Well, kind of. But not like you are suggesting. (And the HAOS change was done after the issue started.)

The change happened over a year ago, on my laptop I use for travel that does not have Home Assistant on it.

It took a series of events for it to finally cause HAOS to fall over. And of all the machines I have that use mDNS, only HASO had the issue, which isn’t that surprising as it’s my only Alpine-based system.

This is a good start for a deeper understanding of the issue:

How to access Home Assistant docker using https on local network?
Docker container not announcing mDNS at 'homeassistant.local'
13

Well, Supervisor is automatically updated and it is hard to disable that feature.
The Supervisor will be updated with new thing it need to check and it often happens without warning.

14

Just in case it helps anyone here, here’s how I detected, found and fixed the issue - it was in the end entirely my fault, but it was particularly tricky to diagnose.
I have homeassistant set up in a virtualbox VM running on a Mac Mini on my home network. It had all been working fine for many months. I have a unifi network. I upgraded my router from a USG to a UCG a few weeks ago, which also included separating devices on the network into VLANs. I made this change and throughout HA continued working fine. Yesterday I noticed homeassistant.local didn’t resolve. I chased my tail thinking it was a broader mDNS issue for some time and tried changing all the Unifi mDNS settings. I had set up mDNS proxy across VLANs because some of the IOT devices I use need it. But eventually I realised that printer.local and other mDNS endpoints were all working fine - it was just HA.
I updated HA OS and core, rebooted. The problem went away. For about 4 minutes. Then came back. In the HA Host logs I discovered a tight loop of systemd resolved conflict detected homeassistant12345 renamed to homeassistant12346. I then googled the error and came across a chain of closed HA github issues all of which referenced each other and each pointing out fixes that contradicted each other. I didn’t understand why this was all broken now.
Eventually, I found the issue when I tried to ssh into the Mac Mini running the HA VM. I blame Apple:
When I was setting up my new Unifi router, I created new VLANs and new SSIDs to separate devices and traffic. In order to set up devices on all these networks, I had to join my phone (an iPhone) to each of the networks to use the many different apps to configure all the IOT stuff I own. Because Apple has the nice ‘feature’ of saving all the network SSIDs and logins between all devices on your iCloud account, my Mac Mini also saved the SSID and login for every separate network on each VLAN. The Mac Mini also has a wired connection. So, randomly, the Mac Mini would sometimes connect to a different SSID putting it on a different VLAN to the wired connection. So HA host would see mDNS reflected queries coming from each interface and it interpreted this as a conflict. Probably causing lots of UDP churn traffic on the network at the same time. The fix was simply to turn wifi off on the Mac Mini.

2 Likes
Mobile App integration misidentifies iPhone 15 Pro