je82 Posted December 21, 2019 Share Posted December 21, 2019 Hello, Never had any issues shutting down my array, but since i started using dockers i now triggered a parity check when shutting down my array. Why? Do i have to manually shut down my docker containers before i shut down the array? I though unraid would be clever enough to shutdown the dockers then the graceful shutdown of the array was issued? Or is something else wrong? Quote Link to comment
Squid Posted December 21, 2019 Share Posted December 21, 2019 Enable Mirror to Flash on syslog server settings, then try to shutdown the array without disabling the containers. After it comes back up, post the resulting syslog file (logs folder on the flash drive), and disable mirror to flash. There's nothing wrong with what you are attempting to do. Quote Link to comment
je82 Posted December 21, 2019 Author Share Posted December 21, 2019 7 minutes ago, Squid said: Enable Mirror to Flash on syslog server settings, then try to shutdown the array without disabling the containers. After it comes back up, post the resulting syslog file (logs folder on the flash drive), and disable mirror to flash. There's nothing wrong with what you are attempting to do. Ok i cancelled the 24 h parity run. Not sure if it happened again or not, i've attached the syslog. Can you explain how a docker container can trigger a parity check if the system was gracefully shutdown? If the array detects problems wouldn't it just leave the system running or is it dead bent on shutting down and will shut down ungracefully if need be even though "power off" should be a graceful shutdown? Ive only started with dockers so i only have a few. The onces i run is: binhex/arch-privoxyvpn x3 (has to be ran in elevated mode for tun0 adapter to work) markusmcnugen/qbittorrentvpn x2 (has to be ran in elevated mode for tun0 adapter to work) binhex/arch-makemkv x1 jlesage/mkvtoolnix x1 in total 7 docker installations, only which of 5 were running when the partiy problem occured after a graceful shutdown. syslog.txt Quote Link to comment
Squid Posted December 21, 2019 Share Posted December 21, 2019 Yeah, it didn't happen The only way this can trigger an unclean shutdown is if the system has to forcibly kill processes because they refused to shutdown normally Quote Link to comment
je82 Posted December 21, 2019 Author Share Posted December 21, 2019 4 minutes ago, Squid said: Yeah, it didn't happen The only way this can trigger an unclean shutdown is if the system has to forcibly kill processes because they refused to shutdown normally damn, thanks for taking a look... strange, i will run the parity run and setup a offsystem logserver if it happens again ill catch it Quote Link to comment
trurl Posted December 21, 2019 Share Posted December 21, 2019 Here is the way unclean shutdown actually works, down in the details. When Unraid boots up, it checks whether or not the array was stopped previously by reading that start/stop status from config/super.dat on flash. When Unraid stops or starts the array, it updates that status on flash. If for some reason Unraid shuts down without updating that status, you get a parity check since the last status shows the array was already started (not stopped). One thing that can cause that status to not get updated is if it actually powers off before it can update the status. That is what happens if you "hard" shutdown. Another thing that can happen is the flash drive is not mounted or not otherwise writable for some reason. This often happens when people are having problems with flash and it gets dropped. This seems to be more common for USB3 ports. And, Unraid will eventually timeout after a few minutes and shutdown anyway even if it can't stop the array. Quote Link to comment
je82 Posted December 21, 2019 Author Share Posted December 21, 2019 3 hours ago, trurl said: Here is the way unclean shutdown actually works, down in the details. When Unraid boots up, it checks whether or not the array was stopped previously by reading that start/stop status from config/super.dat on flash. When Unraid stops or starts the array, it updates that status on flash. If for some reason Unraid shuts down without updating that status, you get a parity check since the last status shows the array was already started (not stopped). One thing that can cause that status to not get updated is if it actually powers off before it can update the status. That is what happens if you "hard" shutdown. Another thing that can happen is the flash drive is not mounted or not otherwise writable for some reason. This often happens when people are having problems with flash and it gets dropped. This seems to be more common for USB2 ports. And, Unraid will eventually timeout after a few minutes and shutdown anyway even if it can't stop the array. Lets say an docker with torrent running is writing to the cache and i hit power off, will this shutdown proper or will it be ungraceful? Is there a way to keep unraid "hanging" rather then bruteforcing a poweroff if the poweroff is made by user? Only reason to bruteforce a poweroff if stuff is not responding is if the device is running on UPS power, but here it seems to do more damage than good. Can i set the timeout for poweroff to be longer somewhere so i give more time to the system? If not i would have time to get the diagnostics locally on the terminal if the system were to hang during poweroff and i would maybe know more of what happened. Quote Link to comment
Frank1940 Posted December 21, 2019 Share Posted December 21, 2019 3 hours ago, trurl said: This seems to be more common for USB2 ports. As I recall, this is more common with USB3 ports than USB2 ports. Quote Link to comment
je82 Posted December 21, 2019 Author Share Posted December 21, 2019 (edited) 11 minutes ago, Frank1940 said: As I recall, this is more common with USB3 ports than USB2 ports. interesting, i did switch from an usb2 port to the internal "on board" usb port a few days ago when i was building my rack setup because i figured it wouldn't be bad for the usb stick to be middle of a windtunnel (4u chassi) rather then stuck in the heat behind the io panel. https://www.supermicro.com/en/products/motherboard/X10SRL-F Looking at that image it does look like the only onboard usb slot is infact a 3.0. Definitely going in and switching back to the usb2.0 port after the parity is done. Edited December 21, 2019 by je82 Quote Link to comment
trurl Posted December 21, 2019 Share Posted December 21, 2019 26 minutes ago, Frank1940 said: As I recall, this is more common with USB3 ports than USB2 ports. Sorry, that's what I meant. Corrected in my post above. 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.