cookwjc

I’d recommend moving on from this plugin; I’ve been and confident you’ll be happier with this other project linked below (not mine). It’s not perfect, but it behaves much better than this one for me at least. Check out Speedtest-tracker https://hub.docker.com/r/henrywhitaker3/speedtest-tracker

@wayner Yes... but you're still better off than me. I have a 1000/50 circuit that is reporting an average of 1.5/.8... If I use version 0.3.4 of the script, i can get a slightly faster 2/5 measurement. I've spent several days verifying network reliability and stability without finding any latency or loss issues to report. Additionally, using iperf, I show full gigabit bi-direction connectivity on the local network. At this point, I believe I've narrowed this down to the unraid host at a minimum, but the iperf results seem to dispell it being a hardware or OS issue. Looking for suggestions to get this reporting correctly - happy to provide logs and troubleshooting if further investigation is desired.

As I was finalizing the debug information for the above post I was able to solve the issue and considered not posting. On the other hand, I've read far too many threads where the author solves their own problem and abandons the thread. So, just in case someone finds themselves in a similar situation in the future, the resolution to this particular problem was to change directory in my active bash session out of the /mnt/user path...

Hi All, I have a situation that is occurring, which is preventing me from being able to stop the array or even successfully issue a shutdown command from the CLI. I did find one article from 2013 referencing an issue with RC13, but I haven't found any discussion regarding newer releases. I'm running 6.2.4 with 14 drives + parity + boot; 12GB RAM; 2 - Xeon 1.??GHz. The system has been stable until this last week when I removed a handful of unused Docker containers and was preparing to shrink the array following 'Clear Drive Then Remove Drive' method from the following article: https://lime-technology.com/wiki/index.php/Shrink_array I (of course) wouldn't expect any changes to have led to this behavior, but I wanted to present the 'what's changed?' answers up front. Dynamix WebUI continues to report 'Spinning up all drives...' however the device lists reports all drives were spun up before initiating the stop command. Also of note, the WebUI is no longer responsive and will not allow new sessions to be established. From the CLI, docker images reports the docker daemon is not currently running (which it was before initiating the array stop) and ps eaf 6 serial TTYs listening, my active pts session, and the ps eaf query, so there don't appear to be any active handles open to mounted disks. The command "fuser -mv /mnt/disk* /mnt/user/*" does return a number of processes items pasted below due to the length of snip. Syslog output shows the following errors recurring: Dec 2 23:44:04 CENTRAL emhttp: Retry unmounting user share(s)... Dec 2 23:44:09 CENTRAL emhttp: shcmd (12033): set -o pipefail ; umount /mnt/user |& logger Dec 2 23:44:09 CENTRAL root: umount: /mnt/user: target is busy Dec 2 23:44:09 CENTRAL root: (In some cases useful info about processes that Dec 2 23:44:09 CENTRAL root: use the device is found by lsof( or fuser(1).) Dec 2 23:44:09 CENTRAL emhttp: err: shcmd: shcmd (12033): exit status: 32 Dec 2 23:44:09 CENTRAL emhttp: shcmd (12034): rmdir /mnt/user |& logger Dec 2 23:44:09 CENTRAL root: rmdir: failed to remove '/mnt/user': Device or resource busy Dec 2 23:44:09 CENTRAL emhttp: shcmd (12035): rm -f /boot/config/plugins/dynamix/mover.cron Dec 2 23:44:09 CENTRAL emhttp: shcmd (12036): /usr/local/sbin/update_cron &> /dev/null Dec 2 23:44:09 CENTRAL emhttp: Retry unmounting user share(s)...