5

Our vagrant box takes ~1h to provision thus when vagrant up is run for the first time, at the very end of provisioning process I would like to package the box to an image in a local folder so it can be used as a base box next time it needs to be rebuilt. I'm using vagrant-triggers plugin to place the code right at the end of :up process.

Relevant (shortened) Vagrantfile:

pre_built_box_file_name = 'image.vagrant'
pre_built_box_path      = 'file://' + File.join(Dir.pwd, pre_built_box_file_name)
pre_built_box_exists    = File.file?(pre_built_box_path)
Vagrant.configure(2) do |config|
  config.vm.box     = 'ubuntu/trusty64'
  config.vm.box_url = pre_built_box_path if pre_built_box_exists
  config.trigger.after :up do
    if not pre_built_box_exists
      system("echo 'Building gett vagrant image for re-use...'; vagrant halt; vagrant package --output #{pre_built_box_file_name}; vagrant up;")
    end
  end
end

The problem is that vagrant locks the machine while the current (vagrant up) process is running:

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

I understand the dangers of two processes provisioning or modifying the machine at one given time, but this is a special case where I'm certain the provisioning has completed.

How can I manually "unlock" vagrant machine during provisioning so I can run vagrant halt; vagrant package; vagrant up; from within config.trigger.after :up?

Or is there at least a way to start vagrant up without locking the machine?

Vigintas Labakojis
  • 1,039
  • 1
  • 15
  • 21
  • Why not just `vagrant up && vagrant halt && vagrant package && vagrant up` from the command line? – Jon Burgess Jul 22 '15 at 00:58
  • Thought a plain `vagrant up` would've taken care of `vagrant box add ...` or `vagrant box remove ... && vagrant box add ...` in case `image.vagrant` file was removed to be re-built. Maybe I'm just overcomplicating things here. – Vigintas Labakojis Jul 22 '15 at 09:04
  • `ps aux | grep "vagrant"` copy PID of process and then `kill -9 ` – andilabs Oct 13 '15 at 06:55

2 Answers2

3

vagrant

This issue has been fixed in GH #3664 (2015). If this still happening, probably it's related to plugins (such as AWS). So try without plugins.

vagrant-aws

If you're using AWS, then follow this bug/feature report: #428 - Unable to ssh into instance during provisioning, which is currently pending.

However there is a pull request which fixes the issue:

So apply the fix manually, or waits until it's fixed in the next release.

In case you've got this error related to machines which aren't valid, then try running the vagrant global-status --prune command.

kenorb
  • 155,785
  • 88
  • 678
  • 743
  • Hi, thanks for the effort, but as you can see in the question, I needed a way to unlock the machine during `vagrant up`. Unrelated to AWS, `vagrant ssh` or `vagrant status`. – Vigintas Labakojis Jun 27 '16 at 13:28
  • The first issue is related to vagrant it-self and sounds like it's fixed, the second part is just in-case you're using aws. – kenorb Jun 27 '16 at 14:10
0

Definitely a bit more of a hack than a solution, but I'd rather a hack than nothing.

I ran into this issue and nothing that was suggested here was working for me. Even though this is 6 years old, it's what came up on a google (along with precious little else), I thought I'd share what solved it for me in case anyone else lands here.

My Setup

I'm using vagrant with ansible-local provisioner on a local virtualbox VM, which provisions remote AWS EC2 instances. (i.e. the ansible-local runs on the virtualbox instance, vagrant provisions the virtualbox instance, ansible handles the cloud). This setup is largely because my host OS is Windows and it's a little easier to take Microsoft out of the equation on this one.

My Mistake

Ran an ansible shell task with a command that doesn't terminate without user input (and did not run it with the & to run in the background).

My Frustration

Even in the linux subsystem, trying a ps aux | grep ruby or ps aux | grep vagrant was unhelpful because the PID would change every time. Probably a reason for this, likely has something to do with how the subsystem works, but I don't know what that reason is.

My Solution

Just kill the AWS EC2 instances manually. In the console, in the CLI, pick your flavor. Your terminal where you were running vagrant provision or vagrant up should then finally complete and spit out the summary output, even if you ctrl + C'd out of the command.

Hoping this helps someone!

acat
  • 596
  • 6
  • 15