Vagrant: `vagrant ssh` locks against other `vagrant ssh` tasks

[r4v5]

vagrant -v:
Vagrant 1.6.5

We have a virtualbox Vagrant VM we're trying to run two tasks on using Foreman on the host machine (OSX Yosemite).
The Procfile we're using is

server: vagrant ssh -c "cd /vagrant && lein run"
worker: vagrant ssh -c "cd /vagrant && lein run -w"

When I run foreman start, the 'worker' process dies with the following message:

13:30:36 server.1     | started with pid 49314
13:30:36 worker.1     | started with pid 49315
13:30:38 worker.1     | Vagrant can't use the requested machine because it is locked! This
13:30:38 worker.1     | means that another Vagrant process is currently reading or modifying
13:30:38 worker.1     | the machine. Please wait for that Vagrant process to end and try
13:30:38 worker.1     | again. Details about the machine are shown below:
13:30:38 worker.1     |
13:30:38 worker.1     | Name: visibility
13:30:38 worker.1     | Provider: virtualbox
13:30:38 worker.1     | exited with code 1
13:30:38 system       | sending SIGTERM to all processes
13:30:38 server.1     | terminated by SIGTERM

This feels really similar to #3664, which was fixed in 1.6.2. It works for my coworker using 1.6.4, but I don't see any commits between 1.6.4 and 1.6.5 that would have affected it.

[drcraig]

I see a similar thing on 1.7.2, but get:

An action 'read_state' was attempted on the machine 'default',
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.

Is this a recurrence of the bug in #3664 or something else?

[nha]

Vagrant 1.7.2, I hit that a lot too, since I use tmuxinator to open multiple connections.

I also tried to modify config.ssh.timeout without visible changes (not sure if this is relevant since this is a Vagrant 1 command).

Would this change with a different provider than virtualbox or another box than ubuntu, or is it completely vagrant-dependant ?

[d3ming]

:+1: also getting this issue lots, vagrant 1.7.2

[ArcTanSusan]

I also get this issue on vagrant 1.7.3. I hope this gets fixed soon. Even destroying all my VMs does not solve the problem.

[till]

Updated from 1.7.2 to 1.7.4 last week and I am now hitting a _similar_ lock-related error when a vagrant up fails.

I can reproduce this as follows:

I am _adding_ an unrelated bug in a chef recipe or shell code which is run to provision a VM. Once the provisioning fails, I am back at the terminal prompt. When I try to provision again, I get a message that another process is locking the command and it seems that my vagrant up is still running in the background.

I usually ps -x |grep [v]agrant to find the offender, kill it and run provision again.

[samsalisbury]

Is anyone able to confirm whether this is expected behaviour, or is there a plan to allow multiple concurrent ssh sessions against a vagrant box as noted in the original report by @r4v5? cc @mitchellh I'm seeing this behaviour on both 1.7.3 and 1.7.4, I haven't tried any other versions.

[sethvargo]

Hi all,

I just tried this on Vagrant master and I am unable to reproduce this issue. I tried via a simple two-terminal-tab approach and via a Procfile. Both commands execute in parallel as expected without a lock or exception. If this isn't fixed in Vagrant 1.7.4, it will definitely be fixed in Vagrant 1.8.

@till the bug you are experiencing is actually completely different, but we've fixed it for Vagrant 1.8 too :smile:

Timeline for Vagrant 1.8 is "end of the month". Thanks everyone! :smile:

[gandra]

Still problem persists, event with vagrant 1.8.1:

http://i.imgur.com/I7sMYdB.png

Host environment: windows 7

[hmijail]

I am seeing what seems to be the same problem in OS X 10.11.5, Vagrant 1.8.1.

(my problem: more than 1 vagrant ssh being launched in parallel end up causing the message

Vagrant can't use the requested machine because it is locked! This
means that another Vagrant process is currently reading or modifying
the machine. Please wait for that Vagrant process to end and try
again. Details about the machine are shown below:

Name: default
Provider: virtualbox

Each one of those vagrant ssh instances launches a short-lived script inside the VM.
The problem takes longer to appear if I make that script slower by injecting a sleep 1. But the problem eventually appears again, sooner than later.

[hmijail]

Workaround: If I dump the vagrant ssh configuration with vagrant ssh-config > myconfig and then instead of vagrant ssh I do ssh -F ./myconfig default, I can open as many ssh sessions as needed.

[hmijail]

(is anyone seeing this, or should I open a new issue?)

[malanve]

Same issue here,
vagrant -v = Vagrant 1.8.1
cat /etc/issue = openSUSE Leap 42.1

New win10x64 box.
vagrant status =
Current machine states:

server not created (virtualbox)

The environment has not yet been created. Run vagrant up to
create the environment. If a machine is not created, only the
default provider will be shown. So if a provider is not listed,
then the machine is not created for that environment.

vagrant up server =
Bringing machine 'server' up with 'virtualbox' provider...
==> server: Importing base box 'win10x64'...
==> server: Matching MAC address for NAT networking...
==> server: Setting the name of the VM: server
==> server: Clearing any previously set network interfaces...
==> server: Preparing network interfaces based on configuration...
server: Adapter 1: nat
server: Adapter 2: hostonly
==> server: Forwarding ports...
server: 3389 (guest) => 3389 (host) (adapter 1)
server: 5985 (guest) => 5985 (host) (adapter 1)
server: 3389 (guest) => 33389 (host) (adapter 1)
server: 5986 (guest) => 55986 (host) (adapter 1)
==> server: Running 'pre-boot' VM customizations...
==> server: Booting VM...
==> server: Waiting for machine to boot. This may take a few minutes...
server: WinRM address: 127.0.0.1:5985
server: WinRM username: vagrant
server: WinRM execution_time_limit: PT2H
server: WinRM transport: plaintext
Vagrant can't use the requested machine because it is locked! This
means that another Vagrant process is currently reading or modifying
the machine. Please wait for that Vagrant process to end and try
again. Details about the machine are shown below:

Name: server
Provider: virtualbox

I rebooted,
I removed all machines in ~/VirtualBox VMs,

vagrant reload server =

==> server: Attempting graceful shutdown of VM...
==> server: Clearing any previously set forwarded ports...
==> server: Clearing any previously set network interfaces...
==> server: Preparing network interfaces based on configuration...
server: Adapter 1: nat
server: Adapter 2: hostonly
==> server: Forwarding ports...
server: 3389 (guest) => 3389 (host) (adapter 1)
server: 5985 (guest) => 5985 (host) (adapter 1)
server: 3389 (guest) => 33389 (host) (adapter 1)
server: 5986 (guest) => 55986 (host) (adapter 1)
==> server: Running 'pre-boot' VM customizations...
==> server: Booting VM...
==> server: Waiting for machine to boot. This may take a few minutes...
server: WinRM address: 127.0.0.1:5985
server: WinRM username: vagrant
server: WinRM execution_time_limit: PT2H
server: WinRM transport: plaintext
==> server: Machine booted and ready!
==> server: Checking for guest additions in VM...
==> server: Setting hostname...
Vagrant can't use the requested machine because it is locked! This
means that another Vagrant process is currently reading or modifying
the machine. Please wait for that Vagrant process to end and try
again. Details about the machine are shown below:

Name: server
Provider: virtualbox

cat Vagrantfile =

-_- mode: ruby -_-

vi: set ft=ruby :

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(2) do |config|

end

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config2|

$script = "
Remove-Item C:/ProgramData/PuppetLabs/puppet/etc/ssl/* -recurse -force
$namet = facter hostname
New-Item -Path C:/vagrant/certs -Name $namet -ItemType directory
Copy-Item -Path C:/vagrant/certs/$namet/* -Destination C:/ProgramData/PuppetLabs/puppet/etc/ssl/ -Recurse -force
puppet agent --test -w 20
$namet = facter hostname
New-Item -Path C:/vagrant/certs -Name $namet -ItemType directory
Copy-Item -Path C:/ProgramData/PuppetLabs/puppet/etc/ssl/* -Destination C:/vagrant/certs/$namet/ -Recurse -force
Restart-Computer -computer server -force
"

config2.vm.define :server do |config2|
config2.vm.box = "win10x64"
config2.vm.communicator = "winrm"
config2.winrm.username = "vagrant"
config2.winrm.password = "vagrant"
config2.vm.network :private_network, ip: "192.168.50.50"
config2.vm.provision "shell", inline: $script
config2.vm.hostname = "server"
config2.vm.network "forwarded_port", host: 33389, guest: 3389
config2.vm.provider "virtualbox" do |v2|
v2.gui=true
v2.name = "server"
v2.customize ["modifyvm", :id, "--memory", "4072"]
end
end
end

[kenorb]

I guess it's fixed in #3664