September 7, 201411 yr Currently stopping the array does not check if certain services are running before trying to take the array offline. For example, if docker is running, then stopping the array ends up in a loop of 'retry unmounting disks' It would be better if this action automatically searches and stops any services running before disabling the array
September 8, 201411 yr For example, if docker is running, then stopping the array ends up in a loop of 'retry unmounting disks' ... similarly, as I've mentioned elsewhere, Xen will also prevent the array from stopping, if its processes are accessing any array drives.
September 9, 201411 yr This issue can be a real pain in the ass. It would be nice if it can check whether the disks are still being access and if so give the user the option to kill the processes that are running, block new connections from opening and stop the array.
September 14, 201411 yr Docker should stop with the array and stop all containers that were running at the time. With VMs, we are looking to change it so the array stop will shutdown all VMs.
September 14, 201411 yr Docker should stop with the array and stop all containers that were running at the time. With VMs, we are looking to change it so the array stop will shutdown all VMs. Qhat about telnet/ssh sessions where the current directory is on an array device? That one often catches me out!
September 15, 201411 yr Docker should stop with the array and stop all containers that were running at the time. With VMs, we are looking to change it so the array stop will shutdown all VMs. That wasn't the case with earlier betas, does beta 9 now handle shutdown of docker correctly?
September 15, 201411 yr based on what dlandon found working with the powerdown script the answer is, "No" As for shutting down VM's ... the powerdown script does create "kill scripts" that operate when the array stops. That is what I use to shut down the VM before the array goes offline.
September 15, 201411 yr hmmm i think this should be a priority for LT and added sooner rather than later, a clean shutdown when using built in tools (docker, xen, and kvm) provided by LT shouldn't require third party scripts (powerdown). jonp - link to comment from dlandon (powerdown) http://lime-technology.com/forum/index.php?topic=31735.msg328335#msg328335
September 15, 201411 yr I'm pretty sure apcupsd is on their 6.0 roadmap and that to me implies powedown as well. Now, who they plan to implement all the functionality is up for grabs. I personally think the kill (and start) scripts are a great way to do it and ideally they can webgui-ize the most common ones like those used for shutting down VM's and dockers while also allowing for the creation of custom ones for people with more special needs
September 15, 201411 yr Community Expert based on what dlandon found working with the powerdown script the answer is, "No" As for shutting down VM's ... the powerdown script does create "kill scripts" that operate when the array stops. That is what I use to shut down the VM before the array goes offline. Using beta 9 if I press the power switch momentarily and watch the console, I can see that the powerdown script is initiated. The subsequent messages indicate that docker IS stopped before the array is stopped. Whether this also means containers are stopped tidily I have no idea.
September 15, 201411 yr Yeah I can't speak to containers. I only KNOW Xen VMs. What I "know" about docker is only what dlandon has stated today in the powerdown / apcupsd plugin threads.
September 15, 201411 yr Community Expert Yeah I can't speak to containers. I only KNOW Xen VMs. What I "know" about docker is only what dlandon has stated today in the powerdown / apcupsd plugin threads. I wonder if some people are still installing a powerdown script via unMenu? If so they might be replacing the one that LimeTech are providing that as far as I can see IS closing things down properly. The one that is available via unMenu is almost certainly not docker or VM aware.
Archived
This topic is now archived and is closed to further replies.