francishe

Running for the last 24h. Perfectly. Thanks again.

Many thanks. Updated.

Thanks for the reply. I've tried switching to the stable version, which gave me the same problem too. Looking forward to the fix.

SOS!!! Help After I was given the notice of an latest update and I did this morning. Then i am being troubled by constant auto-shutdown of my unraid server triggered by NUT. This action was logged: Oct 23 16:50:08 Tower upsmon[4631]: Poll UPS [[email protected]] failed - Server disconnected Oct 23 16:50:08 Tower upsmon[4631]: Communications with UPS [email protected] lost Oct 23 16:50:08 Tower upsmon[4631]: UPS [[email protected]] was last known to be not fully online and currently is not communicating, assuming dead Oct 23 16:50:08 Tower upsmon[4631]: Executing automatic power-fail shutdown Oct 23 16:50:08 Tower upsmon[4631]: Auto logout and shutdown proceeding Oct 23 16:50:13 Tower shutdown[3942]: shutting down for system halt Oct 23 16:50:13 Tower init: Switching to runlevel: 0 Oct 23 16:50:13 Tower init: Trying to re-exec init Oct 23 16:50:14 Tower kernel: mdcmd (36): nocheck cancel Oct 23 16:50:15 Tower emhttpd: Spinning up all drives... Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sdd Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sde Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sdr Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sdf Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sdc Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sdn Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sdq Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sdo Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sdl Oct 23 16:50:15 Tower emhttpd: spinning up /dev/sdp Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdm Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdj Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdk Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdh Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdg Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdd Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sde Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdb Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdr Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdf Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdc Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdn Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdq Oct 23 16:50:34 Tower emhttpd: read SMART /dev/nvme0n1 Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdo Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdl Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdi Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sdp Oct 23 16:50:34 Tower emhttpd: read SMART /dev/sda Oct 23 16:50:35 Tower emhttpd: Stopping services... Oct 23 16:50:35 Tower emhttpd: shcmd (170780): /etc/rc.d/rc.libvirt stop Oct 23 16:50:35 Tower root: Shutting down VM: DSM 710 Oct 23 16:50:35 Tower root: Shutting down VM: Gateway Router Oct 23 16:50:35 Tower root: Shutting down VM: BT Proxy Oct 23 16:50:35 Tower root: Shutting down VM: HuiGuo Proxy Oct 23 16:50:35 Tower root: Shutting down VM: Windows 11 Oct 23 16:50:35 Tower root: Shutting down VM: openwrt test Oct 23 16:50:36 Tower sshd[4678]: Connection from 103.166.11.21 port 43222 on 10.0.0.254 port 22 rdomain "" Oct 23 16:50:37 Tower sshd[4678]: Connection closed by 103.166.11.21 port 43222 [preauth] Oct 23 16:50:43 Tower kernel: br0: port 5(vnet3) entered disabled state Oct 23 16:50:43 Tower kernel: device vnet3 left promiscuous mode Oct 23 16:50:43 Tower kernel: br0: port 5(vnet3) entered disabled state Oct 23 16:50:43 Tower kernel: usb 9-2: reset high-speed USB device number 2 using xhci_hcd Oct 23 16:50:44 Tower kernel: br0: port 3(vnet1) entered disabled state Oct 23 16:50:44 Tower kernel: device vnet1 left promiscuous mode Oct 23 16:50:44 Tower kernel: br0: port 3(vnet1) entered disabled state Oct 23 16:50:47 Tower kernel: br0: port 4(vnet2) entered disabled state Oct 23 16:50:47 Tower kernel: device vnet2 left promiscuous mode Oct 23 16:50:47 Tower kernel: br0: port 4(vnet2) entered disabled state Oct 23 16:51:29 Tower nginx: 2023/10/23 16:51:29 [alert] 9905#9905: worker process 9906 exited on signal 6 Oct 23 16:51:54 Tower kernel: br0: port 7(vnet5) entered disabled state Oct 23 16:51:54 Tower kernel: device vnet5 left promiscuous mode Oct 23 16:51:54 Tower kernel: br0: port 7(vnet5) entered disabled state Oct 23 16:53:19 Tower nginx: 2023/10/23 16:53:19 [alert] 9905#9905: worker process 5570 exited on signal 6 Before this latest version dated 2023.10.22, it was working perfectly for me, never bothered by any problem. I have now disabled the NUT. Thanks

Might be the reason quoted above. I am also sitting behind GFW.

Weird. It disappeared again this morning after my server's reboot. I checked its appdata folder is still there, but .plg file is gone. Why? I am running 6.12.4, where everything is fine except this one.

Please help me find my problem Thanks for the plg. Two days ago I installed it and configured. Yesterday after my server rebooted, it was gone, nowhere to be found in the plugins nor in the settings. I installed again and today i couldn't find it either. In the app center it shows "install" instead of "installed" which I did do. Maybe it doesn't like to stay with me. Please tell me how to let it be with me.

Thanks. Got it done. It's now working perfectly for me.

Hi. guys I have started to use dynamix auto fan control which is working on my unraid server. But what is troubling me is that I can't get it started automatically at system boot/reboot. So I have to manually start it each time after the server boots up. Can anyone tell me how to? Thanks

That would be perfect, before which it still works to my purpose.

Thanks for your advice.

Thanks for your answer. So you mean in my case the parity check shouldn't restart on the array start, ignoring the set time. Anyway it works now. Doesn't matter if the parity check works a little longer than set.

At least for me I need it to run that long because I have a 14T parity drive which usually runs for more than 24 hours for a single parity check and my server sleeps in nights. So I want it to do check in the daytime as long as the server runs till poweroff in the midnight. And your app helps.

Parity check resumed successfully the next day and so far so good. But I am still bewildered about the following setting: Increment resume time at 8:30 but it seemed to have restarted at "Resume array operations on next array start" instead of resuming at 8:30 as set. Which one prevails?

Thanks for the update. I've long been waiting.