'Host' log - constant stream of Hostname conflicts

Configuration
1

Hello all. I’m new to Home Assistant. I’ve been experiencing some instability in my system (mostly random restarts). I’m trying my best to try to figure out if there are any issues, but I’m pretty terrible at reading/understanding logs. In any case, one thing I’ve noticed is that in my Host log, I have a constant stream of messages talking about conflicts. Can anyone give any helpful input here?

I’m running HA on a windows machine:
VirtualBox:
Currently on 2023.5.4.

Through a tutorial I found, I set up NGINX and DuckDNS. They system works, but I’ve had random restarts. This morning I woke up and the system was down. I restarted it and it works, but I’m hoping to improve on the stability. Happy to provide any other info.

Here is an example of what I’m seeing. But again, it’s a constant stream, so new conflict messages appear every time I refresh the log.

Jun 14 15:00:29 homeassistant systemd-resolved[350]: Detected conflict on homeassistant175889.local IN A 192.168.1.40
Jun 14 15:00:29 homeassistant systemd-resolved[350]: Hostname conflict, changing published hostname from 'homeassistant175889' to 'homeassistant175890'.
Jun 14 15:00:29 homeassistant systemd-resolved[350]: Detected conflict on homeassistant175890\032\091a355b03990784f9d9003d8bec2e3fa0f\093._workstation._tcp.local IN SRV 0 0 0 homeassistant175890.local
Jun 14 15:00:29 homeassistant systemd-resolved[350]: Detected conflict on homeassistant175890\032\091a355b03990784f9d9003d8bec2e3fa0f\093._workstation._tcp.local IN TXT ""
Jun 14 15:00:29 homeassistant systemd-resolved[350]: Detected conflict on homeassistant175890\032\091a355b03990784f9d9003d8bec2e3fa0f\093._workstation._tcp.local IN SRV 0 0 0 homeassistant175890.local
Jun 14 15:00:29 homeassistant systemd-resolved[350]: Detected conflict on homeassistant175890\032\091a355b03990784f9d9003d8bec2e3fa0f\093._workstation._tcp.local IN TXT "" ""
Jun 14 14:09:38 homeassistant systemd-resolved[350]: Detected conflict on homeassistant101390.local IN A 192.168.1.40

One other thing I’ve noticed: during the HA boot sequence, I see the error:

[FAILED] Failed to start RPC Bind.

I don’t know if that is related, or if maybe I should start a separate thread, or if it’s not really an issue.

Happy to provide any additional information. Appreciate any input!

2

Possibly related:

Try the fix mentioned in that issue.

3

Hello all. I had originally created this post in the wrong category. The Moderators were kind enough to move this to the “Configuration” category. I’m hoping to get some help with the issue I’ve described in the original post. I’ve looked into the the suggestion by tom_l (mDNS and high CPU usage), but I’m not sure if this is applicable to me. And to be honest, I didn’t really understand much reading through that post (disabling mDNS reflector, etc.).

A couple updates:

I ran two updates this morning:

  1. I updated the HA Core from 2023.5.4 to 2023.6.2

  2. I updated the Home Assistant Operating System to 10.3. I was particularly interested in this because there was a note in the changelog that said “Make sure rpcbind gets started after systemd-tmpfiles is ready”. This made me think maybe my issue of “[FAILED] Failed to start RPC Bind.” may have been addressed in the update. And, sure enough, when restarting HA and watching the scrolling info, I no longer see a message saying “Failed to start RPC Bind”. So I’m hoping that’s one less issue to resolve!

That said, I’m still hoping to figure out how to resolve the main issue of the Host log showing a constant stream of messages talking about changing hostname from “homeassistantXXXXXX” to “homeassistantYYYYYY”.

One final note: I recently went through a major headache of my HA installation failing. It ended up being my SSD that had slowly been dying. All of my backups dating back to 30 days had been corrupted without me even realizing it. So I had to rebuild my install from scratch. The SSD was less than a year old, so I was really surprised. I suspect that all of the logging that HA does puts a good amount of stress on an SSD. That said, I’m wondering if this Host log issue I’m having may have played any part in my previous SSD drive failure.

Looking at the Host log now, it’s running at a pace of around 25 logs per second (see below)

Any help would be appreciated!

See blow. From 33 seconds to 35 seconds, there are about 25 logs.

Jun 19 13:27:33 homeassistant systemd-resolved[333]: Hostname conflict, changing published hostname from 'homeassistant17725' to 'homeassistant17726'.
Jun 19 13:27:34 homeassistant systemd-resolved[333]: Detected conflict on homeassistant17726\032\091a355b03990784f9d9003d8bec2e3fa0f\093._workstation._tcp.local IN SRV 0 0 0 homeassistant17726.local
Jun 19 13:27:34 homeassistant systemd-resolved[333]: Detected conflict on homeassistant17726\032\091a355b03990784f9d9003d8bec2e3fa0f\093._workstation._tcp.local IN TXT 
Jun 19 13:27:34 homeassistant systemd-resolved[333]: Detected conflict on homeassistant17726\032\091a355b03990784f9d9003d8bec2e3fa0f\093._workstation._tcp.local IN SRV 0 0 0 homeassistant17726.local
Jun 19 13:27:34 homeassistant systemd-resolved[333]: Detected conflict on homeassistant17726\032\091a355b03990784f9d9003d8bec2e3fa0f\093._workstation._tcp.local IN TXT 
Jun 19 13:27:34 homeassistant systemd-resolved[333]: Detected conflict on homeassistant17726.local IN A 192.168.1.40
Jun 19 13:27:34 homeassistant systemd-resolved[333]: Hostname conflict, changing published hostname from 'homeassistant17726' to 'homeassistant17731'.
Jun 19 13:27:34 homeassistant systemd-resolved[333]: Detected conflict on homeassistant17731\032\091a355b03990784f9d9003d8bec2e3fa0f\093._workstation._tcp.local IN SRV 0 0 0 homeassistant17731.local
Jun 19 13:27:34 homeassistant systemd-resolved[333]: Detected conflict on homeassistant17731\032\091a355b03990784f9d9003d8bec2e3fa0f\093._workstation._tcp.local IN TXT 
Jun 19 13:27:34 homeassistant systemd-resolved[333]: Detected conflict on homeassistant17731\032\091a355b03990784f9d9003d8bec2e3fa0f\093._workstation._tcp.local IN SRV 0 0 0 homeassistant17731.local
Jun 19 13:27:34 homeassistant systemd-resolved[333]: Detected conflict on homeassistant17731\032\091a355b03990784f9d9003d8bec2e3fa0f\093._workstation._tcp.local IN TXT 
Jun 19 13:27:34 homeassistant systemd-resolved[333]: Detected conflict on homeassistant17731.local IN A 192.168.1.40
Jun 19 13:27:34 homeassistant systemd-resolved[333]: Hostname conflict, changing published hostname from 'homeassistant17731' to 'homeassistant17736'.
Jun 19 13:27:34 homeassistant systemd-resolved[333]: Detected conflict on homeassistant17736\032\091a355b03990784f9d9003d8bec2e3fa0f\093._workstation._tcp.local IN SRV 0 0 0 homeassistant17736.local
Jun 19 13:27:34 homeassistant systemd-resolved[333]: Detected conflict on homeassistant17736\032\091a355b03990784f9d9003d8bec2e3fa0f\093._workstation._tcp.local IN TXT 
Jun 19 13:27:34 homeassistant systemd-resolved[333]: Detected conflict on homeassistant17736\032\091a355b03990784f9d9003d8bec2e3fa0f\093._workstation._tcp.local IN SRV 0 0 0 homeassistant17736.local
Jun 19 13:27:34 homeassistant systemd-resolved[333]: Detected conflict on homeassistant17736\032\091a355b03990784f9d9003d8bec2e3fa0f\093._workstation._tcp.local IN TXT 
Jun 19 13:27:34 homeassistant systemd-resolved[333]: Detected conflict on homeassistant17736.local IN A 192.168.1.40
Jun 19 13:27:34 homeassistant systemd-resolved[333]: Hostname conflict, changing published hostname from 'homeassistant17736' to 'homeassistant17744'.
Jun 19 13:27:34 homeassistant systemd-resolved[333]: Detected conflict on homeassistant17744\032\091a355b03990784f9d9003d8bec2e3fa0f\093._workstation._tcp.local IN SRV 0 0 0 homeassistant17744.local
Jun 19 13:27:34 homeassistant systemd-resolved[333]: Detected conflict on homeassistant17744\032\091a355b03990784f9d9003d8bec2e3fa0f\093._workstation._tcp.local IN TXT 
Jun 19 13:27:34 homeassistant systemd-resolved[333]: Detected conflict on homeassistant17744\032\091a355b03990784f9d9003d8bec2e3fa0f\093._workstation._tcp.local IN SRV 0 0 0 homeassistant17744.local
Jun 19 13:27:34 homeassistant systemd-resolved[333]: Detected conflict on homeassistant17744\032\091a355b03990784f9d9003d8bec2e3fa0f\093._workstation._tcp.local IN TXT 
Jun 19 13:27:34 homeassistant systemd-resolved[333]: Detected conflict on homeassistant17744.local IN A 192.168.1.40
Jun 19 13:27:34 homeassistant systemd-resolved[333]: Hostname conflict, changing published hostname from 'homeassistant17744' to 'homeassistant17752'.
Jun 19 13:27:35 homeassistant systemd-resolved[333]: Detected conflict on homeassistant17752\032\091a355b03990784f9d9003d8bec2e3fa0f\093._workstation._tcp.local IN SRV 0 0 0 homeassistant17752.local
4

Sorry, one other update: I loaded an instance of my HA install that was prior to setting up NGINX, thinking maybe that had something to do with the issue. But even then I was still having the Hostname conflict issue.

5

Was there any resolution you found that worked?

6

I am having the exact same issue as op.

7

Same errors in my log after a power failure and difficulties in starting back up the virtual machine. I always have issue starting up after a power failure (no clean shutdown). I will do a restart to see if it helps

Dec 04 17:21:40 homeassistant systemd-resolved[349]: Detected conflict on homeassistant87117\032\09153a3bdb1ad124765ad7632ac288ecf2d\093._workstation._tcp.local IN TXT ""
Dec 04 17:21:40 homeassistant systemd-resolved[349]: Detected conflict on homeassistant87117.local IN AAAA fe80::c92e:ea3d:1f8c:d828
Dec 04 17:21:40 homeassistant systemd-resolved[349]: Hostname conflict, changing published hostname from 'homeassistant87117' to 'homeassistant87122'.
Dec 04 17:21:40 homeassistant systemd-resolved[349]: Detected conflict on homeassistant87122\032\09153a3bdb1ad124765ad7632ac288ecf2d\093._workstation._tcp.local IN SRV 0 0 0 homeassistant87122.local
Dec 04 17:21:40 homeassistant systemd-resolved[349]: Detected conflict on homeassistant87122\032\09153a3bdb1ad124765ad7632ac288ecf2d\093._workstation._tcp.local IN TXT ""
Dec 04 17:21:40 homeassistant systemd-resolved[349]: Detected conflict on homeassistant87122.local IN AAAA fd0c:9621:d1a2:493c:de04:4864:5c91:ac65
Dec 04 17:21:40 homeassistant systemd-resolved[349]: Hostname conflict, changing published hostname from 'homeassistant87122' to 'homeassistant87126'.
Dec 04 17:21:40 homeassistant systemd-resolved[349]: Detected conflict on homeassistant87126\032\09153a3bdb1ad124765ad7632ac288ecf2d\093._workstation._tcp.local IN TXT ""
Dec 04 17:21:40 homeassistant systemd-resolved[349]: Detected conflict on homeassistant87126\032\09153a3bdb1ad124765ad7632ac288ecf2d\093._workstation._tcp.local IN SRV 0 0 0 homeassistant87126.local
8

For anyone still bumping on this thread, I opened a bug with on home-assistant’s supervisor repository. The description of the issue also contains a solution that worked for me so far, although I tend to think that some future updates will revert the change to default.

1 Like
9

Yeah, still seeing this problem in July 2025 with HA 16.0. This add-on did the trick, thanks!

11

This hit me last night. Supervisor got updated to 2026.01.0.

I’m not quite clear on the issue or how it applies to my situation – or if 2026.01.0 somehow rolled-back a previous fix.

I have a single LAN subnet, so no mDNS reflector, and only a single interface defined in Proxmox for the VM. That is, I’m not clear how I might be multi-homed.

# ip a | grep 192
    inet 192.168.0.70/24 brd 192.168.0.255 scope global noprefixroute enp6s18

I did the suggested fix which stopped the flood in the logs and the CPU and memory issues.

# nmcli connection modify "Supervisor enp6s18" connection.mdns resolve

But, it doesn’t seem like my host name is being advertised. I changed it in the UI and that didn’t seem to advertise it either.

With that fix how to do you get the host to advertise the hostname?

I’m also unclear if the add-on is still needed as a fix, as I thought I read that HAOS will respect changes to NetManager.

Could someone please bring me up to date?

ip address on the host 
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: enp6s18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 02:83:81:60:1e:fc brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.70/24 brd 192.168.0.255 scope global noprefixroute enp6s18
       valid_lft forever preferred_lft forever
    inet6 fe80::35ae:e8b8:6425:a2b/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether fa:a0:0e:f5:48:58 brd ff:ff:ff:ff:ff:ff
    inet 172.30.232.1/23 brd 172.30.233.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::f8a0:eff:fef5:4858/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever
4: hassio: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether b2:6f:0a:d0:cf:3d brd ff:ff:ff:ff:ff:ff
    inet 172.30.32.1/23 brd 172.30.33.255 scope global hassio
       valid_lft forever preferred_lft forever
    inet6 fd0c:ac1e:2100::1/48 scope global nodad
       valid_lft forever preferred_lft forever
    inet6 fe80::b06f:aff:fed0:cf3d/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever
5: vethf5805e1@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
    link/ether d2:e6:c6:86:c4:07 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::d0e6:c6ff:fe86:c407/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever
6: veth8d01bcd@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
    link/ether 5a:f0:08:21:61:39 brd ff:ff:ff:ff:ff:ff link-netnsid 1
    inet6 fe80::58f0:8ff:fe21:6139/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever
7: vethcb4813b@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
    link/ether a6:c4:bd:de:e6:5b brd ff:ff:ff:ff:ff:ff link-netnsid 1
    inet6 fe80::a4c4:bdff:fede:e65b/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever
8: veth3d032f3@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
    link/ether 0e:c2:96:94:ce:f8 brd ff:ff:ff:ff:ff:ff link-netnsid 2
    inet6 fe80::cc2:96ff:fe94:cef8/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever
9: veth9e8decf@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
    link/ether 52:c8:ee:59:89:f2 brd ff:ff:ff:ff:ff:ff link-netnsid 3
    inet6 fe80::50c8:eeff:fe59:89f2/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever
10: veth08751f6@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
    link/ether c6:44:e2:33:51:c1 brd ff:ff:ff:ff:ff:ff link-netnsid 4
    inet6 fe80::c444:e2ff:fe33:51c1/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever
11: vetha1c355c@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
    link/ether 52:ca:13:6f:06:72 brd ff:ff:ff:ff:ff:ff link-netnsid 5
    inet6 fe80::50ca:13ff:fe6f:672/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever
12: vethd3dbd30@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
    link/ether 36:b4:23:af:49:74 brd ff:ff:ff:ff:ff:ff link-netnsid 6
    inet6 fe80::34b4:23ff:feaf:4974/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever
13: veth9cd12c6@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
    link/ether ee:58:be:0c:54:62 brd ff:ff:ff:ff:ff:ff link-netnsid 7
    inet6 fe80::ec58:beff:fe0c:5462/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever
# ip a | grep 192
    inet 192.168.0.70/24 brd 192.168.0.255 scope global noprefixroute enp6s18
#
12

The no mDNS reflector was wrong – I guess.

I have a travel laptop running Ubuntu (not running HA) that I use as a sandbox. Turns out over a year ago I was running a Docker container that needed mDNS but wasn’t run in host mode. So I enabled mDNS reflection in avahi.

Then maybe a month ago I plugged it into ethernet, which brought up the ethernet interface but also kept the wifi interface up. Both on the same subnet.

Then last week Supervisor was auto-updated and (not knowing the code) it announced its hostname which got reflected by the latptop and started the endless loop of hostname conflicts.

The remaining question I have is this: Why did HAOS end up in the mDNS loop, but none of my other machines that all announce their names end up in the same loop? Something specific to HAOS or maybe the mDNS implementation on Alpine?