-
Notifications
You must be signed in to change notification settings - Fork 95
deb Installation doesn't survive VM restart #1039
Comments
@lachnerd can you please post the file /var/log/docker-volume-vsphere.log from the VM thats showing this behavior. Post a restart the docker-volume-vsphere service should be available and can be checked either via "ps -ef|grep docker" or preferrably "service --status-all" and check the status of Docker and docker-volume-vsphere services. |
Hi, thanks for answering heres the Log File:
|
@lachnerd - reading through the message you seem to be doing the following steps (please confirm so we can try to reproduce and investigate) :
Is it correct ? What steps are missing / were different ? The plugin missing in if you can send the results of |
Hi,
Results of I tried to reproduce this on a brandnew ubuntu vm, installed 17.03.0-ce and tried to install the deb File and got an error: |
@lachnerd - thanks for the info. The last issue you are hitting is #1023 . It is fixed in the master so if you build the .deb you'd get it fixed. Our current plan is to have 0.13 release around end of March and this will be fixed there too. Unfortunately the original issue is caused by Docker in 1.13 API hanging if called before full initialization . We are changing out code to accommodate an will update the issue when the build is available |
Volume discovery was written to address chalenges with docker/plugin startup order, and as potential auto-recovery for plugin crashes. * We do not see crashes often (as a matter of fact, only once so far , with VMCI memory issues - and it' fixed). * Docker now manages the order of plugin invocation/startup with Managed Plugins. * and, the last but not the least, during the discovery we make assumption about Docker API availablity, but Docker makes API available only AFTER full startup including plugin initializion, so it could lead to bug like #1039, where docker either hangs for 15-20 sec (like with unmanaged plugin) or steps on it's own bugs and crash (like with managed plugin) In the spirit of taking care of the "sunny day" first, when everything works OK and our code does not crash, this commit turns off discovery on startup. Managed plugin handes all restrts and remounts fine. Unmanaged plugin may have issues if we crash, but first of all we never crash :-) and second unmanaged plugins are getting depreciated anyways
Volume discovery was written to address challenges with docker/plugin startup order, and as potential auto-recovery for plugin crashes. * We do not see crashes often (as a matter of fact, only once so far , with VMCI memory issues - and it' fixed). * Docker now manages the order of plugin invocation/startup with Managed Plugins. * and, the last but not the least, during the discovery we make assumption about Docker API availability, but Docker makes API available only AFTER full startup including plugin initialization, so it could lead to bug like #1039, where docker either hangs for 15-20 sec (like with legacy plugin) or steps on it's own bugs and crash (like with managed plugin) In the spirit of taking care of the "sunny day" first, when everything works OK and our code does not crash, this commit turns off discovery on startup. Managed plugin handles all restarts and remounts fine. Legacy plugin may have issues if we crash, but first of all we never crash :-) and second legacy plugins are getting depreciated anyways
Volume discovery was written to address challenges with docker/plugin startup order, and as potential auto-recovery for plugin crashes. * We do not see crashes often (as a matter of fact, only once so far , with VMCI memory issues - and it' fixed). * Docker now manages the order of plugin invocation/startup with Managed Plugins. * and, the last but not the least, during the discovery we make assumption about Docker API availability, but Docker makes API available only AFTER full startup including plugin initialization, so it could lead to bug like #1039, where docker either hangs for 15-20 sec (like with legacy plugin) or steps on it's own bugs and crash (like with managed plugin) In the spirit of taking care of the "sunny day" first, when everything works OK and our code does not crash, this commit turns off discovery on startup. Managed plugin handles all restarts and remounts fine. Legacy plugin may have issues if we crash, but first of all we never crash :-) and second legacy plugins are getting depreciated anyways
Volume discovery was written to address challenges with docker/plugin startup order, and as potential auto-recovery for plugin crashes. * We do not see crashes often (as a matter of fact, only once so far , with VMCI memory issues - and it' fixed). * Docker now manages the order of plugin invocation/startup with Managed Plugins. * and, the last but not the least, during the discovery we make assumption about Docker API availability, but Docker makes API available only AFTER full startup including plugin initialization, so it could lead to bug like #1039, where docker either hangs for 15-20 sec (like with legacy plugin) or steps on it's own bugs and crash (like with managed plugin) In the spirit of taking care of the "sunny day" first, when everything works OK and our code does not crash, this commit turns off discovery on startup. Managed plugin handles all restarts and remounts fine. Legacy plugin may have issues if we crash, but first of all we never crash :-) and second legacy plugins are getting depreciated anyways
…1047) * Disabled volume discovery and added env var to enable it if needed Volume discovery was written to address challenges with docker/plugin startup order, and as potential auto-recovery for plugin crashes. * We do not see crashes often (as a matter of fact, only once so far , with VMCI memory issues - and it' fixed). * Docker now manages the order of plugin invocation/startup with Managed Plugins. * and, the last but not the least, during the discovery we make assumption about Docker API availability, but Docker makes API available only AFTER full startup including plugin initialization, so it could lead to bug like #1039, where docker either hangs for 15-20 sec (like with legacy plugin) or steps on it's own bugs and crash (like with managed plugin) In the spirit of taking care of the "sunny day" first, when everything works OK and our code does not crash, this commit turns off discovery on startup. Managed plugin handles all restarts and remounts fine. Legacy plugin may have issues if we crash, but first of all we never crash :-) and second legacy plugins are getting depreciated anyways * commented out crash recovery test to match removing of crash recovery
Hi,
i'm using "docker-volume-vsphere" on some VMs running Ubuntu 16.04.2 LTS.
I installed them as follows:
sudo dpkg -i docker-volume-vsphere_0.12.3f64805_amd64.deb
Everythings working fine i see my vsphere Volumes and i'm able to use them etc.
But if i restart the VM vpshere support for docker is gone.
docker volume ls
doesn't show me any vsphere volumes, i have to install the deb again although the installed files from it are still existing (for example "/usr/local/bin/docker-volume-vsphere")So i have to install the docker-volume-vsphere everytime system reboots wich is pretty annoying.
Any tipps on that ?
The text was updated successfully, but these errors were encountered: