Vagrant: Vagrant destroy triggers preventing box destruction with --force

[tomjn]

Force destroying a vagrant instance does not force destroy a vagrant instance if triggers fail for any reason

Vagrant version

❯ vagrant -v
Vagrant 2.1.1

Host operating system

MacOS High Sierra 10.13.4 (17E202)

Guest operating system

  config.vm.box = "ubuntu/trusty64"

Running in Virtualbox

Vagrantfile

https://github.com/Varying-Vagrant-Vagrants/VVV/blob/0d6137b772951b3dadfc3ae29ab4410cd0bf047c/Vagrantfile

Debug output

❯ vagrant destroy -f
==> default: Running triggers before destroy ...
==> default: Running trigger: VVV Pre-Destroy...
    default: Running: inline script
    default: /tmp/vagrant-shell: line 1: /vagrant/config/homebin/vagrant_destroy: No such file or directory
==> default: Trigger run failed
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.

After running vagrant halt:

❯ vagrant destroy c4cacf9
==> default: Running triggers before destroy ...
==> default: Running trigger: VVV Pre-Destroy...
Could not run remote script on default because its state is poweroff
~/dev/git/CD-USB-Generator/vvv git::master 
❯ vagrant destroy c4cacf9 --force
==> default: Running triggers before destroy ...
==> default: Running trigger: VVV Pre-Destroy...
Could not run remote script on default because its state is poweroff

Expected behavior

Destroying the box with the --force parameter should destroy the box/VM

Actual behavior

The box was not destroyed. Unless the VM is provisioned, up, and able to run the remote script, vagrant destroy is nonfunctional, requiring intervention via the VirtualBox interface

Steps to reproduce

1. Add the following trigger to the vagrant file:

  config.trigger.before :destroy do |trigger|
    trigger.name = "Impossible trigger, Pre-Destroy"
    trigger.run_remote = { inline: "command that can never run succesfully" }
  end

1. Attempt to destroy the VM using the vagrant command with --force

All attempts fail, either because the VM is either unprovisioned, turned off, or the command fails.

[briancain]

Hey @tomjn ! This is expected behavior. If your trigger run or run_remote script fails, Vagrant will exit. That said, you can configure the trigger to continue on error.

config.trigger.before :destroy do |trigger|
    trigger.name = "Impossible trigger, Pre-Destroy"
    trigger.run_remote = { inline: "command that can never run succesfully" }
    trigger.on_error = :continue
  end

Thanks!

[tomjn]

That's what we've done, but it's decidedly unexpected, and undocumented. I thought that --force would force it. It would seem --force no longer does anything

[tomjn]

How might I configure it so that I get the behaviour of :continue but still have the ability to --force when the VM is completely f*cked up without having to pull up the VirtualBox? How do I reliably destroy a vagrant box in a situation where I don't care about normal behaviour?

And importantly, what does --force actually do now that the behaviour has changed?

E.g. in my situation, vagrant halting was useful, it provided me with information, but because --force did not work, I ended up stuck, and had to modify the vagrant file, something our users are not expected to be able to do. Adding the on_error isn't the a full solution

[briancain]

@tomjn - the --force flag is specifically for ignoring the confirmation for the destroy command.

Usage: vagrant destroy [options] [name|id]
    -f, --force                      Destroy without confirmation.
...

The option is documented here under the trigger configuration section: https://www.vagrantup.com/docs/triggers/configuration.html#on_error

[tomjn]

So if I end up with a vagrant box in an unknown/broken state and don't know my way around the vagrant file or can't, I'm stuck basically with no options. This is going to be a major headache for support.

Is there really no command for "I say we take off and nuke the site from orbit, it's the only way to be sure"? Or something inbetween :continue and :halt? Or another flag that outright destroys the box no questions asked?

[briancain]

Vagrant will try its best to destroy the guest when you run the destroy command, but if that fails there's not much Vagrant can do outside of that. Yes, you can always bring up the VirtualBox interface to manually destroy the guest, but it doesn't sound like that's the problem you have here.

Triggers are essentially like a special shell provisioner. If they fail, then the command has failed. But we've given you an option to continue if an error occurs. If you don't care what happens and just want the guest gone, then it makes sense to configure your destroy triggers to continue on error.

Just for reference... the --force flag has never meant "destroy this machine no matter what". The triggers feature didn't change that. The flag is literally around removing the y/N confirmation when you run the destroy command. If your trigger fails but you'd like to keep going and continue on error, the option is there for you to define that behavior.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.