I updated to this version and when I rebooted the server my Windows 10 VM decided to apply an update.  Needless to say it took too long and the 60 second shutdown timer expired forcing a shutdown.  When this occurred the stop_services events were not executed because the unassigned devices and recycle bin plugins were not stopped.

 

I think that when the timer expires the shutdown does not process any further and the stop_services events are not executed.  It appears the shutdown does not know where in the shutdown process the time out occurred so it just goes on.  I would think the most likely cause of a shutdown time out would be a VM not shutting down.  I've not seen any situations where a plugin shutdown would hang.

 

I did not post this as a bug, because this is probably by design.  It is rather messy to hang on a VM not shutting down, force a shutdown, and do no further shutdown processing though.  Plugins not being stopped/shutdown will create some problems.  i.e unassigned devices not unmounting devices properly.  I think LT should re-think the force shutdown procedure and possibly clean it up a bit.  Maybe the default time out of 60 seconds is too low.

 

I've attached a log.

 

EDIT: The shutdown time-out setting does not take any changes.  I tried to up the time-out setting, but no changes will stick.

syslog-20161111-164225.zip

EDIT: The shutdown time-out setting does not take any changes.  I tried to up the time-out setting, but no changes will stick.

 

It's a small bug, reported, looking for it in ident.cfg.  Edit shutdownTimeout in disk.cfg, and it will work.

I updated to this version and when I rebooted the server my Windows 10 VM decided to apply an update.  Needless to say it took too long and the 60 second shutdown timer expired forcing a shutdown.  When this occurred the stop_services events were not executed because the unassigned devices and recycle bin plugins were not stopped.

 

I think that when the timer expires the shutdown does not process any further and the stop_services events are not executed.  It appears the shutdown does not know where in the shutdown process the time out occurred so it just goes on.  I would think the most likely cause of a shutdown time out would be a VM not shutting down.  I've not seen any situations where a plugin shutdown would hang.

 

I did not post this as a bug, because this is probably by design.  It is rather messy to hang on a VM not shutting down, force a shutdown, and do no further shutdown processing though.  Plugins not being stopped/shutdown will create some problems.  i.e unassigned devices not unmounting devices properly.  I think LT should re-think the force shutdown procedure and possibly clean it up a bit.  Maybe the default time out of 60 seconds is too low.

 

Shutting down a Win 10 system that is insisting on an update is a real problem, especially here in lightning country, no matter if it's bare metal or in a VM.  A timeout won't help, as you don't want to wait.  And you don't want it killed when the "Don't shut off system" message is on the screen, so it either has to die before the update or it has to let it complete.  One safer option is to logout the user, then kill it, either by power off or VM kill (SIG_KILL).

I updated to this version and when I rebooted the server my Windows 10 VM decided to apply an update.  Needless to say it took too long and the 60 second shutdown timer expired forcing a shutdown.  When this occurred the stop_services events were not executed because the unassigned devices and recycle bin plugins were not stopped.

 

I think that when the timer expires the shutdown does not process any further and the stop_services events are not executed.  It appears the shutdown does not know where in the shutdown process the time out occurred so it just goes on.  I would think the most likely cause of a shutdown time out would be a VM not shutting down.  I've not seen any situations where a plugin shutdown would hang.

 

I did not post this as a bug, because this is probably by design.  It is rather messy to hang on a VM not shutting down, force a shutdown, and do no further shutdown processing though.  Plugins not being stopped/shutdown will create some problems.  i.e unassigned devices not unmounting devices properly.  I think LT should re-think the force shutdown procedure and possibly clean it up a bit.  Maybe the default time out of 60 seconds is too low.

 

Shutting down a Win 10 system that is insisting on an update is a real problem, especially here in lightning country, no matter if it's bare metal or in a VM.  A timeout won't help, as you don't want to wait.  And you don't want it killed when the "Don't shut off system" message is on the screen, so it either has to die before the update or it has to let it complete.  One safer option is to logout the user, then kill it, either by power off or VM kill (SIG_KILL).

 

This is going to become a bigger problem as more people adopt Win10.  The updating is basically automatic and the user has no real choice to delay or stop it from happening.  Gone is the option for manual updating at the user convenience.  It will simply happen whenever the OS (and MS) decide to schedule it.  To some extent, I can understand why MS got rid of the option for manual updates but it has the potential to create havoc in certain cases and for some users. 

For Windows 10 updates in my VM's, I take control over this by simply not allowing the Windows Update service to run.  It's clunky, but it effectively gives you control over when and where you update.  The only downside is you won't know about pending updates (the old "Notify, but don't download/install" setting.)

 

A few SC commands in an elevated batch file help to achieve this without mucking around with the services GUI.  One to stop/disable the service:

 

sc stop wuauserv

sc config wuauserv start=disabled

 

...and one to start it up again:

 

sc start wuauserv

sc config wuauserv start=demand

 

Once a week (usually on the weekend) I'll bring the service back up, make sure the updates install, and then disable it again.  I know, it means I might miss a critical security patch in time, but I'm generally comfortable with this.  The other reason I do this is due to my poor rural internet connection - automatic updates essentially drag it to a halt, so this solves that issue for me too.

 

EDIT: Realised this probably shouldn't be in a release thread.  Mods feel free to move!

 

For Windows 10 updates in my VM's, I take control over this by simply not allowing the Windows Update service to run.  It's clunky, but it effectively gives you control over when and where you update.  The only downside is you won't know about pending updates (the old "Notify, but don't download/install" setting.)

 

A few SC commands in an elevated batch file help to achieve this without mucking around with the services GUI.  One to stop/disable the service:

 

sc stop wuauserv

sc config wuauserv start=disabled

 

...and one to start it up again:

 

sc start wuauserv

sc config wuauserv start=demand

 

Once a week (usually on the weekend) I'll bring the service back up, make sure the updates install, and then disable it again.  I know, it means I might miss a critical security patch in time, but I'm generally comfortable with this.  The other reason I do this is due to my poor rural internet connection - automatic updates essentially drag it to a halt, so this solves that issue for me too.

 

Brilliant!

Another alternative, if you have the luxury of never having to worry about losing the power to your machine, and never having to shut down or reboot when you don't want to:

 

Always manually shut down your Windows 10 VMs from within the VM, and you'll never be surprised by updates that take longer than the shutdown timeout. You'll just have to wait for it to finish its crap before you proceed with the host level shutdown or reboot.

 

PS. I had the same thing happen to me when I stupidly shut down the array to reboot for 6.3.0-rc3 to rc4 update. The Patch Tuesday rollup decided to wait until just after the start of Friday's Active Hours range to install itself, and thus did not automatically reboot itself when it completed installing.

This is in fact a bug and I have posted a defect report here: http://lime-technology.com/forum/index.php?topic=53736.0

 

The good news is that the answer is extremely simple.

another option for disabling updates on Win10, is making Ethernet connection as metered.. i use this solution and it simply works google for it - it's one registry key to change..

This is in fact a bug and I have posted a defect report here: http://lime-technology.com/forum/index.php?topic=53736.0

 

The good news is that the answer is extremely simple.

 

Dan, I've looked at the defect report, and I have to say that either I'm not understanding something, or respectfully you haven't read the posts above.  This is not a simple problem, and adding 30 seconds doesn't change anything, may only allow a few more normal shutdowns to complete, could make things worse in a power outage.  It doesn't matter if an updating Windows VM is killed 60 seconds in or 90 seconds in or 900 seconds in, it shouldn't be interrupted when it says "don't turn me off".  Even if it was a huge number, I can see new users in the future, unaware of this problem, having significant issues when Microsoft sends another 'anniversary' size update to them.

 

And it does nothing for the lightning kill problem I mentioned above, which admittedly may require a separate solution.  It's not just a lightning issue, though, as it applies to everyone using a UPS.  Say you're away from home, nobody at all at home, and the power goes out, an extended outage.  Your UPS sends the signal to shutdown the system.  No amount of notifications will matter, there's no one there to act on them.  And the system is going down, ready or not, possibly sooner than later.  The longer the timeout that's set, the more likely the UPS will shut power off before it's done.

 

Ideally, you would want to be able to detect a Windows Update situation, and change shutdown behavior.  If no update, shut down normally.  If update, prompt user for choice (30 second timeout, default to slow kill?) to either allow full completion, or to kill all now, or to log out the user(s), wait 5 more seconds for all buffers flushed to disk, then kill the VM (just my idea, completely untested).  I don't know if there's any way to do this however.

 

I think the solution is going to involve choices available to the user - normal shutdown (non-Windows VMs), normal Windows shutdown (may detect Windows update and behave differently?), and a forced Windows shutdown (emergency shutdown, for lightning and UPS shutdowns, no update allowed).  That way, the UPS would have a special signal or event to call, the emergency one, different from normal shutdowns.  And there would be an 'Emergency' button, for lightning and other emergencies, that calls the same emergency shutdown.  This forced shutdown should make a 'best effort' to safely close everything in a minute or less, then kill anything left.

 

Until something like that is done, in a close lightning situation, I suppose what I would do is manually log out the Windows user, wait a few seconds, kill the VM, then click the unRAID shutdown button, and run off to other things in the house to be shut off.

 

Dan, I do think you may have identified an issue with the order of shutdown processing, as certainly stop_services needs to always be processed.

Read the defect report again.  The delay lets the rc.local_shutdown script finish.  After it times out it issues a force shutdown on VMs and lets the shutdown progress.  As it stands, it's like pulling the plug on a VM.  It's better to force a shutdown that the VM will recover from than just pull the plug.  Does it let the VM finish an update?  No, but that could take minutes and the system needs to shut down quickly at times.  You are looking for a perfect answer that is not practical.  The best answer is to not cause any damage to a VM and let it recover at a later time.

Read the defect report again.  The delay lets the rc.local_shutdown script finish.  After it times out it issues a force shutdown on VMs and lets the shutdown progress.  As it stands, it's like pulling the plug on a VM.  It's better to force a shutdown that the VM will recover from than just pull the plug.  Does it let the VM finish an update?  No, but that could take minutes and the system needs to shut down quickly at times.  You are looking for a perfect answer that is not practical.  The best answer is to not cause any damage to a VM and let it recover at a later time.

This would all be a moot point if KVM save state was properly implemented in unraid.

 

All running VM's could be "hibernated" (virsh save)  instead of shut down when the array was stopped.

KVM save state does not work with PCIe passthrough in effect, last time I checked.

 

E: Verified with virt-manager: "Error: Device has assigned non-USB host devices."

 

E2: Verified working another way, though:

 

virsh dompmsuspend "Windows 10" disk

 

And it still lists as "running" in "virsh list". Definitely requires hibernate / suspend to disk support enabled in the guest, or else it merely shuts down.

 

[...] It's not just a lightning issue, though, as it applies to everyone using a UPS. 

 

 

another though about UPS.. i was always wondering, why stopping the array brings up all drives..

when you are on UPS, and array are idle at all (say all disks are in spin down..), UPS triggers shutdown event at 30% or 5 min. remaining for example - then you need so much power to spin all drives up to do emergency shutdown.. this spin up action can shut ups down cos of lack of power remaining...

another though about UPS.. i was always wondering, why stopping the array brings up all drives..

Yeah that's unfortunate.  The drives are spun up on order to properly un-mount them.  There doesn't seem to exist a concept in linux of 'syncing' a disk and then spinning it down but leaving it 'mounted', ie, a "soft mount".  We could change the spin-down code so that it first unmounts the disk and then spins it down, and then use 'automount' feature to spin it back up and mount "on demand" - but then something like cache-dirs would not work (it would result in keeping disk spun up).

another though about UPS.. i was always wondering, why stopping the array brings up all drives..

Yeah that's unfortunate.  The drives are spun up on order to properly un-mount them.  There doesn't seem to exist a concept in linux of 'syncing' a disk and then spinning it down but leaving it 'mounted', ie, a "soft mount".  We could change the spin-down code so that it first unmounts the disk and then spins it down, and then use 'automount' feature to spin it back up and mount "on demand" - but then something like cache-dirs would not work (it would result in keeping disk spun up).

How much extra time would that on demand automount take? I can see a definite use case for several of my drives to go the extra step of staying offline almost always. Perhaps it could be an extra setting sort of like power states are defined?

i.e.

high demand drives, stays spinning almost always

nearline drives, spindown but stay mounted, must be spun up to stop array

archive drives, unmounted at first spindown, but still available for use if needed

 

The biggest advantage I see besides accelerated array stop is the resistance to crash corruption. If the drive is unmounted when an event happens, chance of corruption is pretty much nil. As it stands right now, there can be some awefully stale data waiting for a sync command.

The biggest advantage I see besides accelerated array stop is the resistance to crash corruption. If the drive is unmounted when an event happens, chance of corruption is pretty much nil. As it stands right now, there can be some awefully stale data waiting for a sync command.

 

The longest stuff hangs around in the linux buffer cache is 30-sec.  If a device is spun down due to inactivity there will be no unflushed data to sync.  There is a 'dirty' bit in each file system superblock however, and this is what gets cleared on an un-mount.