spdelope Posted September 10, 2022 Share Posted September 10, 2022 (edited) I have had this issue for a while and can't quite nail it down. My server will randomly hang and become unresponsive, requiring me to reboot on the machine. Cannot access via webgui, ssh, or via monitor plugged in. Never any real info in the logs from what I can tell. Here are from the last time this happened. My server locked up later around 12:01pm or so but the logs stopped until I rebooted. The last line is concerning. Sep 9 11:53:12 UnRaid-Server kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth367ca58: link becomes ready Sep 9 11:53:12 UnRaid-Server kernel: docker0: port 18(veth367ca58) entered blocking state Sep 9 11:53:12 UnRaid-Server kernel: docker0: port 18(veth367ca58) entered forwarding state Sep 9 11:53:21 UnRaid-Server kernel: docker0: port 18(veth367ca58) entered disabled state Sep 9 11:53:21 UnRaid-Server kernel: vethd0ae93e: renamed from eth0 Sep 9 11:53:21 UnRaid-Server kernel: docker0: port 18(veth367ca58) entered disabled state Sep 9 11:53:21 UnRaid-Server kernel: device veth367ca58 left promiscuous mode Sep 9 11:53:21 UnRaid-Server kernel: docker0: port 18(veth367ca58) entered disabled state Sep 9 11:54:21 UnRaid-Server kernel: docker0: port 18(vethee550ee) entered blocking state Sep 9 11:54:21 UnRaid-Server kernel: docker0: port 18(vethee550ee) entered disabled state Sep 9 11:54:21 UnRaid-Server kernel: device vethee550ee entered promiscuous mode Sep 9 11:54:21 UnRaid-Server kernel: docker0: port 18(vethee550ee) entered blocking state Sep 9 11:54:21 UnRaid-Server kernel: docker0: port 18(vethee550ee) entered forwarding state Sep 9 11:54:21 UnRaid-Server kernel: docker0: port 18(vethee550ee) entered disabled state Sep 9 11:54:21 UnRaid-Server kernel: eth0: renamed from vethd3a5f8d Sep 9 11:54:21 UnRaid-Server kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethee550ee: link becomes ready Sep 9 11:54:21 UnRaid-Server kernel: docker0: port 18(vethee550ee) entered blocking state Sep 9 11:54:21 UnRaid-Server kernel: docker0: port 18(vethee550ee) entered forwarding state Sep 9 11:54:26 UnRaid-Server kernel: docker0: port 18(vethee550ee) entered disabled state Sep 9 11:54:26 UnRaid-Server kernel: vethd3a5f8d: renamed from eth0 Sep 9 11:54:26 UnRaid-Server kernel: docker0: port 18(vethee550ee) entered disabled state Sep 9 11:54:26 UnRaid-Server kernel: device vethee550ee left promiscuous mode Sep 9 11:54:26 UnRaid-Server kernel: docker0: port 18(vethee550ee) entered disabled state Sep 9 11:54:27 UnRaid-Server kernel: general protection fault, probably for non-canonical address 0x49e5ef1403d70: 0000 [#3] SMP NOPTI Sep 9 11:54:27 UnRaid-Server kernel: CPU: 0 PID: 8290 Comm: Disk Tainted: P D W O 5.10.28-Unraid #1 Sep 9 11:54:27 UnRaid-Server kernel: Hardware name: ASUS System Product Name/PRIME Z590-A, BIOS 1202 10/27/2021 Sep 9 11:54:27 UnRaid-Server kernel: RIP: 0010:page_vma_mapped_walk+0x209/0x4dc Edited September 10, 2022 by spdelope Quote Link to comment
spdelope Posted September 10, 2022 Author Share Posted September 10, 2022 unraid-server-diagnostics-20220910-1004.zip Diagnostics attached. I have tried deleting some plugins not used and disabling igmp snooping and stp for the port on my switch and still have the issue. Quote Link to comment
JorgeB Posted September 11, 2022 Share Posted September 11, 2022 Enable the syslog server and post that after a crash. Quote Link to comment
trurl Posted September 11, 2022 Share Posted September 11, 2022 Perhaps unrelated except it might indicate something wrong with your docker configuration: Why do you have 120G docker.img? Have you had problems filling it? 20G is often more than enough. Something that might be related to your problem and could also be caused by docker configuration: What do you get from the command line with this? df -h / Quote Link to comment
spdelope Posted September 11, 2022 Author Share Posted September 11, 2022 4 hours ago, JorgeB said: Enable the syslog server and post that after a crash. I'm the OP, I posted the last few lines from syslog. I have it mirroring to usb Quote Link to comment
spdelope Posted September 11, 2022 Author Share Posted September 11, 2022 2 hours ago, trurl said: Perhaps unrelated except it might indicate something wrong with your docker configuration: Why do you have 120G docker.img? Have you had problems filling it? 20G is often more than enough. Something that might be related to your problem and could also be caused by docker configuration: What do you get from the command line with this? df -h / This is the result from df -h / Filesystem Size Used Avail Use% Mounted on rootfs 16G 1.7G 14G 11% / I had the larger docker image size just to avoid it filling up. I'm at 16gb now and I think I just went to 120 since I have plenty of space on my cache so didn't want to deal with it again. Quote Link to comment
spdelope Posted September 11, 2022 Author Share Posted September 11, 2022 4 hours ago, JorgeB said: Enable the syslog server and post that after a crash. syslog (2)I also posted the syslog file here. I had crashes at Sept 9 12:03p, Sept 4 7:43a, Sept 1 2:54p, Aug 22 2:58a. Thanks for the help Quote Link to comment
JorgeB Posted September 12, 2022 Share Posted September 12, 2022 Jul 26 17:14:29 UnRaid-Server kernel: macvlan_broadcast+0x116/0x144 [macvlan] Jul 26 17:14:29 UnRaid-Server kernel: macvlan_process_broadcast+0xc7/0x110 [macvlan] Macvlan call traces are usually the result of having dockers with a custom IP address and will end up crashing the server, upgrading to v6.10 and switching to ipvlan should fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enabled, top right)). Quote Link to comment
spdelope Posted September 12, 2022 Author Share Posted September 12, 2022 10 hours ago, JorgeB said: Jul 26 17:14:29 UnRaid-Server kernel: macvlan_broadcast+0x116/0x144 [macvlan] Jul 26 17:14:29 UnRaid-Server kernel: macvlan_process_broadcast+0xc7/0x110 [macvlan] Macvlan call traces are usually the result of having dockers with a custom IP address and will end up crashing the server, upgrading to v6.10 and switching to ipvlan should fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enabled, top right)). The only docker I have running in br0 with its own ip address is pihole. I had countless file permission issues with v6.10. Do you think just stopping pihole will resolve my issue? Thank you Quote Link to comment
spdelope Posted September 13, 2022 Author Share Posted September 13, 2022 22 hours ago, JorgeB said: Jul 26 17:14:29 UnRaid-Server kernel: macvlan_broadcast+0x116/0x144 [macvlan] Jul 26 17:14:29 UnRaid-Server kernel: macvlan_process_broadcast+0xc7/0x110 [macvlan] Macvlan call traces are usually the result of having dockers with a custom IP address and will end up crashing the server, upgrading to v6.10 and switching to ipvlan should fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enabled, top right)). I went ahead and turned off the pihole docker (it was a backup to my pi anyways) we'll see how long I can go with out a crash! Quote Link to comment
Solution JorgeB Posted September 13, 2022 Solution Share Posted September 13, 2022 You should still change to ipvlan. Quote Link to comment
spdelope Posted September 13, 2022 Author Share Posted September 13, 2022 45 minutes ago, JorgeB said: You should still change to ipvlan. I would except with the file permission issues I had with 6.10 all the way to 6.10.3. I saw quite a few others with the same problem. Quote Link to comment
spdelope Posted November 9, 2022 Author Share Posted November 9, 2022 On 9/13/2022 at 1:16 AM, JorgeB said: You should still change to ipvlan. Thank you! I upgraded shortly after 6.11 released and made the change and havent had this issue again 1 Quote Link to comment
Recommended Posts
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.