Interrupt detected, quitting waiting for machine to restart

Error message

Interrupt detected, quitting waiting for machine to restart

What it means

The windows-restart provisioner's wait loop also selects on an internal cancel channel (p.cancel). When a cancel is signaled — typically because the enclosing build was interrupted via Ctrl-C or the context was cancelled — the loop abandons waiting and returns this error. It is the provisioner's way of unwinding cleanly on user/environment-initiated interruption rather than a guest failure.

Source

Thrown at provisioner/windows-restart/provisioner.go:205

		// or an interrupt to come through.
		select {
		case <-waitDone:
			if err != nil {
				ui.Error(fmt.Sprintf("Error waiting for machine to restart: %s", err))
				return err
			}

			ui.Say("Machine successfully restarted, moving on")
			close(p.cancel)
			break WaitLoop
		case <-timeout:
			err := fmt.Errorf("Timeout waiting for machine to restart.")
			ui.Error(err.Error())
			close(p.cancel)
			return err
		case <-p.cancel:
			close(waitDone)
			return fmt.Errorf("Interrupt detected, quitting waiting for machine to restart")
		}
	}
	return nil

}

var waitForCommunicator = func(ctx context.Context, p *Provisioner) error {
	runCustomRestartCheck := true
	if p.config.RestartCheckCommand == DefaultRestartCheckCommand {
		runCustomRestartCheck = false
	}
	// This command is configurable by the user to make sure that the
	// vm has met their necessary criteria for having restarted. If the
	// user doesn't set a special restart command, we just run the
	// default as cmdModuleLoad below.
	cmdRestartCheck := &packersdk.RemoteCmd{Command: p.config.RestartCheckCommand}
	log.Printf("Checking that communicator is connected with: '%s'",
		cmdRestartCheck.Command)

View on GitHub (pinned to eb36e3c3e4)

Solutions

Let the build run to completion or press Ctrl-C only when you intend to abort
Re-run the build after an intended interruption; the machine state may need cleanup
If this appears without user interruption, ensure only one Provision run per provisioner instance and update to a recent Packer version for channel-handling fixes
Adjust CI timeouts so external job cancellation does not strike mid-restart

Defensive patterns

Strategy: try-catch

Try / catch

err := p.Provision(ctx, ui, comm, generatedData)
if err != nil && strings.Contains(err.Error(), "Interrupt detected") {
    // treat as user cancellation: clean up and stop gracefully
    return
}

Prevention

Avoid Ctrl-C/CI cancellation during the restart window; size CI timeouts accordingly
Run one Provision per provisioner instance to avoid p.cancel channel races
Handle cancellation gracefully in wrappers: release guest resources before exiting
Keep Packer updated for improvements to cancel-channel handling

When it happens

Trigger: The wait loop's `<-p.cancel` case fires: the user pressed Ctrl-C during `packer build` while waiting for the Windows machine to restart, or another path closed p.cancel (notably, the success path also closes p.cancel, so a racing/goroutine-leak scenario can surface this error unexpectedly).

Common situations: User aborts a build mid-reboot; CI job cancelled/timed out externally killing packer; reruns or tests where p.cancel is closed concurrently causing the interrupt branch to trigger.

Related errors

AI-assisted analysis of hashicorp/packer@eb36e3c3e4 (2026-09-05). Data as JSON: /api/errors/6ca8c0627dad5fcc. Report an issue: GitHub.