HAOS mDNS failed last night

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?

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

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

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?

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.

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

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

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

Ah, I’m not alone:

1 Like

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

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.

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:

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.