November 9, 20169 yr Unraid 6.2.4. I experienced an issue when upgrading to 6.2.3 (also 6.2.4). The symptom...after the plugin updated unraid a reboot is needed. I stopped the array then clicked reboot and the chrome tab in my VM browser said system is rebooting and then the VM shutdown as it should when the array is stopped. When I rebooted unraid, the array was set to auto start and the VM was set to auto start. Once the VM was up and running and I opened chrome (since my chrome setting was set to "continue where I left off"), it opened the unraid tab that had the unraid is rebooting status message...and I am assuming that this somehow was sending the stop array function and would immediately shut down the VM. Forum users that were providing feedback suggested that I add this post to the defect report forum. Here is a link to my thread in the KVM subforum: http://lime-technology.com/forum/index.php?topic=53510.0 By changing my chrome setting to the "open a new tab" setting my system is stable. kode54 in the forum above suggested the following solution/items for consideration: Future suggestion for anyone listening: Do not command your unRAID to shut down from within the VM, until a fix for this issue has been issued. Suggested fix for unRAID developers: For shutdown/reboot, and any other web interface page that does things like this (sits on a status page), do the following: Possible 1) Tie a random session key to the URL that commands the shutdown. It can remain compatible with random scripts that command it externally by accepting "no session key GET parameter" as valid, while also accepting "wrong session key GET parameter" as an error and failing to perform the action. The web interface will clearly pass a session key, so cached instances of the tab do not inadvertently reboot the machine again when they are reloaded. Possible 2) Have the URLs that handle these types of actions immediately redirect to another page, combined with using a POST method to trigger the originating script. That way, the browser will cache the target of the redirect as the current tab contents, and any attempt to navigate back to that page should also ask the user if they wish to resubmit. Combine with the above, using a different session key each time a command is invoked, and you end up with a script that hopefully won't reactivate if the same form contents are resubmitted to it. Maintain as a separate API than anything that needs an immediate GET action to just fire it off.
Archived
This topic is now archived and is closed to further replies.