Closed Sharpie closed 8 years ago
Simple reproduction case:
Vagrant.configure('2') do |config|
config.vm.provider :aws do |p, o|
# AWS configuration.
end
config.vm.define :test do |node|
# Some long-running provisioner
node.vm.provision :shell, inline: 'sleep 300'
end
end
Run vagrant provision test
in one terminal. Open a separate terminal and attempt vagrant status
or vagrant ssh test
. Both will fail with:
An action 'get_state' was attempted on the machine 'test',
but another process is already executing an action on the machine.
Vagrant locks each machine for access by only one process at a time.
Please wait until the other Vagrant process finishes modifying this
machine, then try again.
If you believe this message is in error, please check the process
listing for any "ruby" or "vagrant" processes and kill them. Then
try again.
@rtyler Any thoughts on this patch? It's a small change that eases a lot of pain.
:+1: This fix would save me a lot of hassle when working with AWS instances. Some of my provisioning scripts fail because of it.
Prior to this patch long running operations, such as provisioners, would prevent
vagrant status
orvagrant ssh
from being run due to Vagrant action locking. Attempting such actions would result in an error message. This is inconvienant as shelling into a VM is a common debugging step in figuring out why a provisioner is taking longer than usual.Vagrant 1.7 introduced the ability to mark certain actions as not requireing a lock. This patch adds
lock: false
to theget_state
andget_ssh_info
calls which allows bothvagrant status
andvagrant ssh
to function while a long-running action is executing in another process. Vagrant 1.6 will ignore the unknownlock
option and fail as usual.