Timeout behavior inconsistency across Vagrant provisioner types

Vagrant documents that setting a timeout on a provisioner sends an interrupt signal when the limit is exceeded and marks the provision as failed. However, observed behavior differs: some provisioner types (e.g., shell) leave the virtual machine running after a timeout, while others (e.g., Ansible) appear to trigger a vagrant halt. The underlying decision point—whether Vagrant core or the specific provisioner implementation initiates the halt—is not clearly defined in the documentation.

Goal: clarify what determines the VM state after a provisioner timeout and whether users can enforce a consistent outcome across provisioner types.

Constraints: rely only on the documented timeout attributes and environment variables; avoid assuming undocumented internal signals.

Uncertainty: it is unclear if the halt behavior is configurable, hard‑coded per provisioner, or dependent on the provisioner’s exit handling.

Which provisioner types cause Vagrant to halt the VM on timeout?
Is the halt behavior controllable via Vagrantfile settings or environment variables?
Can users guarantee a uniform VM state (either always running or always halted) regardless of the provisioner used?