Capt.Insano Posted October 18, 2021 Share Posted October 18, 2021 (edited) Everytime I reboot or shutdown my system a parity check starts when it powers back up. I am aware from reading other topics that this usually means an unclean shutdown but there is no errors appearing in the syslog during the shutdown process. I have read a very similar topic here: I based on that topic, have tried replacing my flash-drive to a new one and have tried chaging the shutdown timeout as per this comment in above thread: "Timeout appears to be kicking sooner than it should, go to Settings - Disk Settings and change the shutdown timeout to a different value just to re-apply, set it to like 60 secs." But still I get a parity check starting after reboot. Diags Attached, I would greatly appreciate any help. Thanks to all. tower-diagnostics-20211018-1428.zip Edited October 30, 2021 by Capt.Insano Quote Link to comment
Frank1940 Posted October 18, 2021 Share Posted October 18, 2021 Try stopping the array from the Main tab and time how long it takes for the array to stop. That will tell you if the 'Shutdown time-out' value is correct. 1 Quote Link to comment
Capt.Insano Posted October 18, 2021 Author Share Posted October 18, 2021 I timed how long it took to stop the array from the Main tab: 1 minute & 9 Seconds. Could it be that 90 secs is not long enough in my setup for all my VMs (x3) and Docker Containers (x30+) to shutdown fully if something like a windows update kicks in? I am going to up the timeout to 180 secs and see if a parity check starts on reboot. Quote Link to comment
Capt.Insano Posted October 18, 2021 Author Share Posted October 18, 2021 (edited) This seems to have fixed it. Increasing the timeout to a high vaue (180 secs in my case) has ensured enough time for safe shutdown even in the event of a Windows update during VM shutdown. Thanks @Frank1940. Update: See below, problem returned after array runnning for any length of time. Edited October 20, 2021 by Capt.Insano Quote Link to comment
Squid Posted October 18, 2021 Share Posted October 18, 2021 3 minutes ago, Capt.Insano said: This seems to have fixed it. Increasing the timeout to a high vaue (180 secs in my case) has ensured enough time for safe shutdown even in the event of a Windows update during VM shutdown. Thanks @Frank1940. The real solution though is in VM Settings you change it to hibernate the VM's instead of Shutting Down and install the Virtio Guest Tools (on the Virtio ISO disk you used to set up the ethernet ports etc in Windows) Million reasons why Windows can take quite a while to shut down (or just plain refuses to) and hibernating the VM instead of attempting to shut it down solves that problem easily. Quote Link to comment
Capt.Insano Posted October 19, 2021 Author Share Posted October 19, 2021 Spoke too soon, Just tried another clean reboot there and again a parity check started after power up: Diags attached again. Any further advice? tower-diagnostics-20211019-1001.zip Quote Link to comment
JorgeB Posted October 19, 2021 Share Posted October 19, 2021 You're still getting an unclean shutdown, first thing you can do is to press array stop and see how long it takes to stop, and if it does, second thing is to post the diags saved on the flash drive after the latest unclean shutdown, they are generated automatically. Quote Link to comment
Capt.Insano Posted October 19, 2021 Author Share Posted October 19, 2021 (edited) Hi @JorgeB, Diags were attached to the post above yours, these were the diags from the latest unclean shutdown (this morning) that caused the parity check again. I will try and stop the array manually again and time it when I get home but as per one of my prev posts above; the last time it took 1 min 9 secs to stop and the disk timeout in my settings is now 180 secs Edited October 19, 2021 by Capt.Insano Quote Link to comment
JorgeB Posted October 19, 2021 Share Posted October 19, 2021 15 minutes ago, Capt.Insano said: Diags were attached to the post above yours, 3 hours ago, JorgeB said: post the diags saved on the flash drive after the latest unclean shutdown, they are generated automatically. Not the same, diags you posted are after rebooting. Quote Link to comment
Capt.Insano Posted October 19, 2021 Author Share Posted October 19, 2021 @JorgeB Sorry, I didn't realise there were other logs: Attached are the 2 zips dated today from /boot/logs Are these the diags that you were after? Thanks for the help BTW tower-diagnostics-20211019-0953.zip tower-diagnostics-20211019-1001.zip Quote Link to comment
JorgeB Posted October 19, 2021 Share Posted October 19, 2021 Oct 19 09:53:41 Tower emhttpd: shcmd (37287): umount /mnt/cache Oct 19 09:53:41 Tower root: umount: /mnt/cache: target is busy. Something was still using cache. Quote Link to comment
Capt.Insano Posted October 19, 2021 Author Share Posted October 19, 2021 2 hours ago, JorgeB said: Oct 19 09:53:41 Tower emhttpd: shcmd (37287): umount /mnt/cache Oct 19 09:53:41 Tower root: umount: /mnt/cache: target is busy. Something was still using cache. Anyway of figuring what was using Cache? If I monitor top/htop during a shutdown would that tell me? Quote Link to comment
JorgeB Posted October 19, 2021 Share Posted October 19, 2021 There might be, but don't know how, someone else might have a suggestion. Quote Link to comment
Squid Posted October 19, 2021 Share Posted October 19, 2021 /etc/libvirt didn't unmount because it was still in use. Quote Link to comment
Capt.Insano Posted October 19, 2021 Author Share Posted October 19, 2021 1 hour ago, Squid said: /etc/libvirt didn't unmount because it was still in use. I followed your recommendation of changing my VMs to hibernate instead of shutdown, any other recommendations seeing as libvirt is the culprit? Quote Link to comment
Squid Posted October 19, 2021 Share Posted October 19, 2021 @JorgeB might know, but I seem to recall that there was an issue at some point with the VM system not always honoring the shutdown timer (but it seems to work fine for me) (And you did also install the guest tools in the VM?) Quote Link to comment
Capt.Insano Posted October 19, 2021 Author Share Posted October 19, 2021 18 minutes ago, Squid said: @JorgeB might know, but I seem to recall that there was an issue at some point with the VM system not always honoring the shutdown timer (but it seems to work fine for me) (And you did also install the guest tools in the VM?) I did, infact they were already installed but I also updated them and all drivers to latest stable: virtio-win-0.1.208 Quote Link to comment
JorgeB Posted October 20, 2021 Share Posted October 20, 2021 12 hours ago, Squid said: but I seem to recall that there was an issue at some point with the VM system not always honoring the shutdown timer That turned out to be a false issue, at least so far, and it's not the problem here: Oct 19 09:50:38 Tower shutdown[16774]: shutting down for system reboot ... Oct 19 09:51:45 Tower root: Waiting on VMs to hibernate............................................................ Oct 19 09:51:45 Tower root: Domain 86349a06-14bd-3361-c257-9064d80fe376 is being shutdown Oct 19 09:51:45 Tower root: Oct 19 09:51:45 Tower root: Domain 37dc3718-c315-0f42-39de-4a1ab8e25771 is being shutdown Oct 19 09:51:45 Tower root: VM timeout is set to 60 secs, and it wasn't enough, and looks like they didn't force shutdown either since libvirt was still in use after this. Quote Link to comment
Capt.Insano Posted October 20, 2021 Author Share Posted October 20, 2021 I updated VM shutdown time-out to 180 secs and still a parity check after reboot. I have 3 VMs as you can probably see from prev logs: HomeAssistant VM (Hassio) PiHole (Debian Based) Windows 10 (With latest virtio-win-0.1.208 drivers installed) New diags (from USB key) attached. tower-diagnostics-20211020-0819.zip Quote Link to comment
JorgeB Posted October 20, 2021 Share Posted October 20, 2021 53 minutes ago, Capt.Insano said: I updated VM shutdown time-out to 180 You need to increase the general timeout, they can't be the same or the second one will kick in, still it looks like 180 wasn't enough for the VMs to shutdown, do they shutdown if you stop the array? If yes post new diags after doing that. Quote Link to comment
Capt.Insano Posted October 20, 2021 Author Share Posted October 20, 2021 Just stopped the array from the Main Tab, it completed successfully but took 4mins 14secs! Attached is the diag from this. not sure what is causing such a delay? tower-diagnostics-20211020-1902.zip Quote Link to comment
JorgeB Posted October 20, 2021 Share Posted October 20, 2021 7 minutes ago, Capt.Insano said: it completed successfully but took 4mins 14secs! So then you'dneed to set the VM timeout to like 5 minutes and set the general timeout to 6 minutes, or just shutdown the VMs manually before rebooting/stopping the array, that's what I do. Quote Link to comment
JonathanM Posted October 20, 2021 Share Posted October 20, 2021 1 hour ago, JorgeB said: shutdown the VMs manually before rebooting/stopping the array, that's what I do. To extend that a little, you should definitely install either apcupsd or nut software, whichever you have managing the host Unraid, on each VM, and set it to shut down the VM pretty much immediately when power goes out, that way the VM's are already down and Unraid can shut itself down without hanging. Both nut and apcupsd can be easily configured to watch a host instance and react. Quote Link to comment
Capt.Insano Posted October 21, 2021 Author Share Posted October 21, 2021 17 hours ago, JonathanM said: To extend that a little, you should definitely install either apcupsd or nut software, whichever you have managing the host Unraid, on each VM, and set it to shut down the VM pretty much immediately when power goes out, that way the VM's are already down and Unraid can shut itself down without hanging. Both nut and apcupsd can be easily configured to watch a host instance and react. Thanks for this advice, I will defo do this. @JorgeB & @Squid I think I have found the issue that is causing the excessive shutdown times at the moment (and possibly the unclean shutdowns): libvirt is not hibernating my linux VMs. My Windows 10 VM will hibernate no problem either during array stop, unraid shutdown or by manually triggering a hibernation here: But if I try the same with either my PiHole VM (ubuntu based) or HomeAssistant OS VM(Hassio) nothing happens: This screenshot was after clicking the "Hibernate" button, nothing happens and the VM does not hibernate (same with HassOS VM) I think they are just sitting there (ignoring the hibernation command) causing the libvirt timeout to be reached and then being force-closed. Should linux VMs be able to hibernate from libvirt? Quote Link to comment
Capt.Insano Posted October 30, 2021 Author Share Posted October 30, 2021 Issue, marked as solved. Defo a VM issues not an unRAID issue. Thanks to all and thanks to devs 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.