March 30, 20188 yr I had to reboot a Debian machine (not unRAID) just some days ago because it lost state of one share from a Windows machine i rebooted. I could have continued to use the Debian machine but I really needed to be able to mount the same share again and any new mount attempt would hang with process state 'D' which means uninterruptible wait for I/O. It's quite likely that you have one guilty process that is waiting for SMB data from the other machine on a now dead TCP connection. And since it's in a critical section within in the kernel, any other process that wants access to the same resource will also get stuck. One trick I missed testing is to fake TCP/IP data to try to force close TCP connections that has huge timeout times. But that isn't an easy path to take without proper tools - normal users aren't intended to be able to generate and inject arbitrary TCP packets so it isn't supported by any normally available tools.
March 30, 20188 yr 2 minutes ago, bonienl said: Could you try again with unRAID 6.5.1-rc2 installed? In the syslog this is reported: 0 08:38:06 Tower kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000038 Mar 30 08:38:06 Tower kernel: IP: tcp_push+0x4e/0xee After this a call trace is recorded and you get the famous "connection time out" message, you mentioned earlier. From this point on communication hangs. The above should be resolved in rc2 which has the kernel patch for the TCP bug. Sure, I'll forcefully shutdown the server now and will upgrade to 6.5.1-rc2. Should the server hang again, I'll let you guys know.
March 30, 20188 yr 6.5.1-rc3 is just released. It reverts Docker version back to the one used in unRAID 6.4.1. Give this a try.
March 30, 20188 yr 8 minutes ago, bonienl said: 6.5.1-rc3 is just released. It reverts Docker version back to the one used in unRAID 6.4.1. Give this a try. Just updated to rc3, currently rebooting. Will let you know if the problem persists.
April 3, 20188 yr Had a few issues after updating to rc3 (unraid was telling me partition issues and so on) but this was fixed with swapping usb to another port (had it on usb3 port, now usb2). Since then there were no other issues, docker is running smoothly until now.
April 14, 20188 yr I am on 6.5.0 and have this issue. Culprit appears to be pihole docker container. Is there a solution on how to force stop as normal 'docker stop <id>' is not working. I would prefer not to have to do an unclean system reboot. Edit: After going back and reading previous posts, I found my answer: # pkill -f docker # /etc/rc.d/rc.docker start Edited April 14, 20188 yr by noski
Archived
This topic is now archived and is closed to further replies.