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, 20214 yr by Capt.Insano

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. 

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.

 

 

 

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, 20214 yr by Capt.Insano

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.

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

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.

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, 20214 yr by Capt.Insano

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.

@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

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.

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?

There might be, but don't know how, someone else might have a suggestion.

/etc/libvirt didn't unmount because it was still in use.

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?

@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?)

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

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.

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

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.

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

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.

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.

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?

 

 

 

 

Issue, marked as solved.

 

Defo a VM issues not an unRAID issue.

 

Thanks to all and thanks to devs