April 5, 20251 yr The past 2 weeks I have been experiencing a very worrisome issue where my qbitorrent container appears to be running but is stuck in a state where it actually isn't doing anything. I cannot stop, restart, kill, or remove the container. All attempts just say that the action cannot be performed. The other scarier issue is that when this 1 container acts up, I cannot stop or restart the array at all. Unraid gets into a loop where it constantly tries to unmount the array but cannot. I have to reboot the entire server and perform a parity check, I have had to do this at least 3 times in the past 2 weeks. When parity check completes I never have any errors that need to be corrected. I believe these 2 issues are linked together but I do not know how and why this is happening. I have attached my diagnostic file from when I was trying to stop the array but couldn't. If another diagnostic report is needed I can provide another. I would appreciate any help I could get, thank you! unraid-r720xd-diagnostics-20250405-1314.zip
April 5, 20251 yr try process of elimination/simplification. If you kill docker, then do you regain control of array? If yes, then ... I dunno (in my case storage unresponsiveness has been from network-interface-timeouts). If no, then keep eliminating complications. My latest torrent sticking has been due to conflicts between tailscale and other VPNs, the workaround is to use one VPN at a time, so I kill tailscale as needed. Did you look at your qbittorrent log-tab, or configure it to save to file for review, to see what it says is happening? EDIT- reading some of your logs (syslog.txt), your UPS says it is going dead, take it out of use, and see what happens then. Ethernet interface "leaving promiscuous mode" often? Is that mode expected? Also it seemed like your docker was shutdown, and an hour later your system had problems shutting down the array anyway. It's a beautiful mess, all right. Please post followup as you get details or resolve it. Edited April 5, 20251 yr by msstolemyrefs
April 6, 20251 yr Author 5 hours ago, msstolemyrefs said: try process of elimination/simplification. If you kill docker, then do you regain control of array? If yes, then ... I dunno (in my case storage unresponsiveness has been from network-interface-timeouts). If no, then keep eliminating complications. My latest torrent sticking has been due to conflicts between tailscale and other VPNs, the workaround is to use one VPN at a time, so I kill tailscale as needed. Did you look at your qbittorrent log-tab, or configure it to save to file for review, to see what it says is happening? EDIT- reading some of your logs (syslog.txt), your UPS says it is going dead, take it out of use, and see what happens then. Ethernet interface "leaving promiscuous mode" often? Is that mode expected? Also it seemed like your docker was shutdown, and an hour later your system had problems shutting down the array anyway. It's a beautiful mess, all right. Please post followup as you get details or resolve it. I have an ups connected to my synology that acts as an ups server and I have unraid using it and unraid never reports correct battery info. The ups battery is only a few months old and completely full but unraid always reports it as running low for some reason while synology reports it as full. My docker torrent client doesn’t use Tailscale, I just have it setup to access my server remotely. there is nothing in the container logs that show any errors. Actually now that I look at it the only thing in the logs for the container are from when it initially starts and nothing after. Is that normal or is there a way to get it to log more? I have 2 torrent containers and the other one hasn’t ever had any issues at all, both running the same client and version. I should not that the problematic container has more activity than the other one. I’m not sure if “leaving promiscuous mode” is normal, I don’t not know what that even is unfortunately. I did update unraid to 7.0.1 since posting and the problem container has been running without errors since, can just be a coincidence but worth noting. Edited April 6, 20251 yr by Android_18
April 7, 20251 yr Author So this just happened again and I'm having to do another parity check. i noticed in the unraid logs a lot of "cifs: vfs: send error in write = -11" errors. i have a smb share to a local drive on my network that the docker client I have been having problems with is downloading to when this weird state on my server happens. I have attached another diagnostic file when this happened after i forced a restart with idrac. unraid-r720xd-diagnostics-20250407-0051.zip
April 7, 20251 yr Community Expert Syslog starts over after every boot, enable the syslog server and post that after it happens again.
April 9, 20251 yr Author ok I enabled syslog server and the issue happened again. I did not reboot but I did try to stop the container and got the same error that it couldn't be stopped. If you need me to force a reboot and post diagnostic again please let me know. unraid-r720xd-diagnostics-20250409-0010.zip
April 9, 20251 yr Community Expert There's nothing relevant logged that I can see, suggesting more an issue with that particular container, you can try recreating the docker image to see if it helps: https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file Then: https://docs.unraid.net/unraid-os/manual/docker-management/#re-installing-docker-applications Also see below if you have any custom docker networks: https://docs.unraid.net/unraid-os/manual/docker-management/#docker-custom-networks
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.