January 28, 20233 yr Community Expert Hi My logs are full of these messages : Jan 28 16:55:01 Tower avahi-daemon[24594]: New relevant interface veth4df0c00.IPv6 for mDNS. Jan 28 16:55:01 Tower avahi-daemon[24594]: Registering new address record for fe80::4c8d:85ff:fe22:ba26 on veth4df0c00.*. Jan 28 16:59:52 Tower kernel: docker0: port 8(veth4df0c00) entered disabled state Jan 28 16:59:52 Tower kernel: veth389904f: renamed from eth0 Jan 28 16:59:52 Tower avahi-daemon[24594]: Interface veth4df0c00.IPv6 no longer relevant for mDNS. Jan 28 16:59:52 Tower avahi-daemon[24594]: Leaving mDNS multicast group on interface veth4df0c00.IPv6 with address fe80::4c8d:85ff:fe22:ba26. Jan 28 16:59:52 Tower kernel: docker0: port 8(veth4df0c00) entered disabled state Jan 28 16:59:52 Tower kernel: device veth4df0c00 left promiscuous mode Jan 28 16:59:52 Tower kernel: docker0: port 8(veth4df0c00) entered disabled state Jan 28 16:59:52 Tower avahi-daemon[24594]: Withdrawing address record for fe80::4c8d:85ff:fe22:ba26 on veth4df0c00. Jan 28 17:00:09 Tower kernel: docker0: port 8(vethc56628d) entered blocking state Jan 28 17:00:09 Tower kernel: docker0: port 8(vethc56628d) entered disabled state Jan 28 17:00:09 Tower kernel: device vethc56628d entered promiscuous mode Jan 28 17:00:09 Tower kernel: eth0: renamed from veth67bdfe2 Jan 28 17:00:09 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethc56628d: link becomes ready Jan 28 17:00:09 Tower kernel: docker0: port 8(vethc56628d) entered blocking state Jan 28 17:00:09 Tower kernel: docker0: port 8(vethc56628d) entered forwarding state Jan 28 17:00:11 Tower avahi-daemon[24594]: Joining mDNS multicast group on interface vethc56628d.IPv6 with address fe80::78f4:80ff:fe8c:fe48. Jan 28 17:00:11 Tower avahi-daemon[24594]: New relevant interface vethc56628d.IPv6 for mDNS. Jan 28 17:00:11 Tower avahi-daemon[24594]: Registering new address record for fe80::78f4:80ff:fe8c:fe48 on vethc56628d.*. I can't find the source of the problem. Can someone help me please ? Diagnostics are attached tower-diagnostics-20230128-1711.zip
January 29, 20233 yr Community Expert Stop all docker containers then start enabling one by one to see if you can find the culprit.
January 29, 20233 yr Author Community Expert Thanks I had read this thread on the forum before your reply. I disabled all my dockers without really finding the culprit. I then reactivated everything and since then, no more messages in the logs!
February 4, 20233 yr Community Expert Check the advanced view on the docker page and look at container uptime, that's typically a container that keeps crashing/restarting due to bad config or such.
February 6, 20233 yr Solution I have the same issue. I added "Homer" as docker container from the CAS. Using "bridge" as network for the docker does not start the container and gives me: Feb 6 16:49:53 SERVER kernel: docker0: port 5(veth9adb836) entered blocking state Feb 6 16:49:53 SERVER kernel: docker0: port 5(veth9adb836) entered disabled state Feb 6 16:49:53 SERVER kernel: device veth9adb836 entered promiscuous mode Feb 6 16:49:53 SERVER kernel: docker0: port 5(veth9adb836) entered blocking state Feb 6 16:49:53 SERVER kernel: docker0: port 5(veth9adb836) entered forwarding state Feb 6 16:49:53 SERVER kernel: docker0: port 5(veth9adb836) entered disabled state Feb 6 16:49:53 SERVER kernel: docker0: port 5(veth9adb836) entered disabled state Feb 6 16:49:53 SERVER kernel: device veth9adb836 left promiscuous mode Feb 6 16:49:53 SERVER kernel: docker0: port 5(veth9adb836) entered disabled state When I give the container an IPv4 address from my custom network on interface br0 it starts up without errors. So I guess its somehow related with the bridging. Edit: Maybe I may add: This is the only container that does not start using bridge as interface. I have several other containers running well with bridge. Edit 2: OK I guess I found it. For me it was port related. I had another docker container using port 8080. Unraid did not warn me that the port is already in use (I thought it did in the past, maybe a bug??). But I used another port and now the container starts. Edited February 6, 20233 yr by UnKwicks
February 11, 20233 yr Author Community Expert Hi Back from holiday All my dockers are up more than 2 days so no problems about accidental restart. A port of unifi-controller was using 8080. I changed it to 8082. I watch the logs now
February 12, 20233 yr Author Community Expert No more logs for today, I think I can say it's solved Thanks
September 18, 20232 yr On 2/11/2023 at 2:36 PM, deadnote said: Hi Back from holiday All my dockers are up more than 2 days so no problems about accidental restart. A port of unifi-controller was using 8080. I changed it to 8082. I watch the logs now I'm having the same issue and Unifi is using 8080 on mine as well. Can you tell me why it using 8080 is bad? Like why did you even think that was the problem? 😄 Obviously you fixed it, I'm just curious why in the world that made a difference! 😄 Thanks!
September 19, 20232 yr 5 hours ago, deadnote said: Because 8080 was used by another docker service Ah okay. Makes sense. I thought this was some sort of fix for anyone with Unifi. 😄 I've read several threads on this and seen several comments that these lines in the log are normal. Guess I'll just let it be. 🙂 Thanks!
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.