January 13, 20242 yr Having some weird networking behavior on Unraid 6.12.6. I'm periodically losing access to the management GUI and SMB shares on my server. The loss of access seems to be for 30 seconds to 3 minutes in duration. Curiously, the Docker containers I have running remain accessible during these outages (both those using custom IP and bridging) and I can still ping the server's IP. I've done the usual reboots, tried disabling bonding, tried only having one NIC connected, tried a BIOS update. Other devices I have that are connected to the same network are not having similar issues. tower-diagnostics-20240113-1351.zip
January 14, 20242 yr Community Expert Nothing jumps out in the log, do you know the time it lasted happened?
January 14, 20242 yr You have docker containers needing updates: Jan 13 13:24:00 Tower root: Fix Common Problems: Warning: Docker Application homeassistant has an update available for it Jan 13 13:24:00 Tower root: Fix Common Problems: Warning: Docker Application Pihole-DoT-DoH has an update available for it Jan 13 13:24:00 Tower root: Fix Common Problems: Warning: Docker Application plex has an update available for it Jan 13 13:24:00 Tower root: Fix Common Problems: Warning: Docker Application sonarr-1 has an update available for it Jan 13 13:24:00 Tower root: Fix Common Problems: Warning: Docker Application Stash has an update available for it One is pihole. Update the docker containers and see if it helps.
January 15, 20242 yr Author 5 hours ago, dlandon said: You have docker containers needing updates: Jan 13 13:24:00 Tower root: Fix Common Problems: Warning: Docker Application homeassistant has an update available for it Jan 13 13:24:00 Tower root: Fix Common Problems: Warning: Docker Application Pihole-DoT-DoH has an update available for it Jan 13 13:24:00 Tower root: Fix Common Problems: Warning: Docker Application plex has an update available for it Jan 13 13:24:00 Tower root: Fix Common Problems: Warning: Docker Application sonarr-1 has an update available for it Jan 13 13:24:00 Tower root: Fix Common Problems: Warning: Docker Application Stash has an update available for it One is pihole. Update the docker containers and see if it helps. Those containers being out-of-date existed before the problem occurred. I updated the containers anyway, no change.
January 15, 20242 yr Author 14 hours ago, JorgeB said: Nothing jumps out in the log, do you know the time it lasted happened? I think in the log I posted the most recent occurrence was in the last 10 minutes. The only log entry that I don't ever recall seeing before this problem happened is "Tower monitor: Stop running nchan processes".
January 15, 20242 yr Author Some other things I've noticed in testing: SSH connections are being refused, and the following code block shows up in the log around the same time as I lose connection to the server: Jan 14 22:14:46 Tower kernel: veth1cd4618: renamed from eth0 Jan 14 22:14:46 Tower kernel: docker0: port 2(veth6436d01) entered disabled state Jan 14 22:14:47 Tower kernel: docker0: port 2(veth6436d01) entered disabled state Jan 14 22:14:47 Tower kernel: device veth6436d01 left promiscuous mode Jan 14 22:14:47 Tower kernel: docker0: port 2(veth6436d01) entered disabled state Jan 14 22:15:01 Tower kernel: docker0: port 2(veth6c69648) entered blocking state Jan 14 22:15:01 Tower kernel: docker0: port 2(veth6c69648) entered disabled state Jan 14 22:15:01 Tower kernel: device veth6c69648 entered promiscuous mode Jan 14 22:15:01 Tower kernel: docker0: port 2(veth6c69648) entered blocking state Jan 14 22:15:01 Tower kernel: docker0: port 2(veth6c69648) entered forwarding state Jan 14 22:15:01 Tower kernel: docker0: port 2(veth6c69648) entered disabled state Jan 14 22:15:15 Tower kernel: eth0: renamed from veth29ff5eb Jan 14 22:15:15 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth6c69648: link becomes ready Jan 14 22:15:15 Tower kernel: docker0: port 2(veth6c69648) entered blocking state Jan 14 22:15:15 Tower kernel: docker0: port 2(veth6c69648) entered forwarding state
January 18, 20242 yr Author Further investigating, memtest86 shows memory errors. However, my config is 2 sticks of 16GB DDR4 ECC. Both sticks showed errors in memtest86, both individually and in pairs, and in all slots, which makes me think the memory isn't actually the problem. The odds of 2 sticks failing simultaneously seem very small to me. I've ordered a new stick of ECC DDR4 to try, but I'm starting to think this is a CPU or motherboard issue.
January 18, 20242 yr Community Expert 1 hour ago, sylinen said: but I'm starting to think this is a CPU or motherboard issue. That's a strong possibility.
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.