hashicorp/vagrant · error

vagrant.trigger.abort

Error message

vagrant.trigger.abort

What it means

This is the warning emitted by Vagrant's trigger engine when a Vagrantfile trigger is configured with on_error: :abort (or a Ruby trigger block calls trigger_abort). In the normal (non-parallel) path Vagrant prints 'Vagrant has been configured to abort. Terminating now...' and then hard-exits the process via Process.exit!(exit_code). Inside a parallel batch action (vagrant up --parallel) it instead stores the exit code on the worker thread and terminates just that thread so remaining actions can finish.

Source

Thrown at lib/vagrant/plugin/v2/trigger.rb:352

            else
              @logger.debug("Trigger run encountered an error. Continuing on anyway...")
              @machine.ui.error(e.message)
            end
          end
        end

        # Exits Vagrant immediately
        #
        # @param [Integer] code Code to exit Vagrant on
        def trigger_abort(exit_code)
          if Thread.current[:batch_parallel_action]
            @ui.warn(I18n.t("vagrant.trigger.abort_threaded"))
            @logger.debug("Trigger abort within parallel batch action. " \
              "Setting exit code and terminating.")
            Thread.current[:exit_code] = exit_code
            Thread.current.terminate
          else
            @ui.warn(I18n.t("vagrant.trigger.abort"))
            @logger.debug("Trigger abort within non-parallel action, exiting directly")
            Process.exit!(exit_code)
          end
        end

        # Calls the given ruby block for execution
        #
        # @param [Proc] ruby_block
        def execute_ruby(ruby_block)
          ruby_block.call(@env, @machine)
        end
      end
    end
  end
end

View on GitHub (pinned to 35f3160f4a)

Solutions

1. If the abort is unintended, change the trigger's on_error behavior: replace :on_error => :abort with :on_error => :continue (or remove it) in the Vagrantfile trigger block.
2. If the abort is intended but you need cleanup, move cleanup into the trigger itself before calling trigger_abort, because Process.exit! skips Ruby at_exit handlers.
3. For parallel runs, remember the exit code is per-thread (Thread.current[:exit_code]); check the batch action summary to see which machine aborted rather than expecting an immediate process exit.
4. Inspect debug logs (LOG_LEVEL=debug vagrant up) for the lines 'Trigger abort within parallel batch action' or 'Trigger abort within non-parallel action' to confirm which path executed.

Example fix

# before
config.trigger.after :up do |trigger|
  trigger.run = { inline: "./deploy.sh" }
  trigger.on_error = :abort   # any failure kills the whole vagrant process via Process.exit!
end

# after
config.trigger.after :up do |trigger|
  trigger.run = { inline: "./deploy.sh" }
  trigger.on_error = :continue # failure is logged, Vagrant keeps going
end

# Before relying on trigger behavior, dry-run the Vagrantfile config
require "vagrant"
# inspect triggers without executing them:
#   vagrant validate  (checks Vagrantfile syntax)
# and grep the Vagrantfile for abort-on-error triggers:
#   grep -n "on_error" Vagrantfile
# ensure it reads `on_error = :continue` unless a hard abort is intended

In a Ruby plugin wrapping actions, rescue nothing here: trigger_abort in the non-parallel path calls Process.exit! which cannot be caught (it skips SystemExit handling). Guard instead by checking the configured trigger's on_error value before executing the triggered command.

When it happens

Trigger: A Vagrantfile defines config.trigger.after :up, :on_error => :abort (or a :type => :ruby trigger whose block calls trigger_abort(code)), and the triggered action fails; or you run any command under a batch parallel action (vagrant up with machine_set parallelism) and the trigger fires there.

Common situations: Teams adding deploy/test hooks to Vagrantfile triggers that intentionally halt on failure; CI pipelines that expect a specific exit code; users confused why the whole Vagrant process dies (exit! skips at_exit handlers, so cleanup code and tmp files may be skipped) or why under --parallel only one machine aborted while others kept running.

Related errors

• There was an error parsing the Vagrantfile: No config was gi
• The command '%{cmd}' was not found for this trigger.
• The `privileged` setting for option `run` for trigger comman
• The setting `powershell_args` is not supported for the trigg
• `false` is not a valid option for the `abort` option for a t

AI-assisted analysis of hashicorp/vagrant@35f3160f4a (2026-08-21). Data as JSON: /api/errors/0393ebb353ee2fc8. Report an issue: GitHub.