Controller shutdown and reboot

In System → Kerrigan → Controller power, a System Admin can request a shutdown or reboot of the host running Kerrigan. Confirm the selected action in the dialog. This affects the entire controller host, including other services hosted on that machine. It sends no power commands to DevKits.

The host schedules the action one minute after accepting it. The dashboard, API, and fleet management become unavailable while the controller is down. After a reboot, reconnect once the host and its containers have started. After a shutdown, physical or out-of-band access is required to power the host back on.

Preparation and graceful stopping

Stop submitting work and let current work finish before using these controls. Requests are rejected while firmware updates, bootstrap jobs, or known active device operations are present. The host also prevents power operations during software updates, and software updates during a pending power operation. These checks do not automatically drain the fleet or prevent new work during the one-minute delay. Coordinate the maintenance window with other operators and CI clients. Controller-dependent tasks and connections may be interrupted.

The privileged Ubuntu host updater performs the operation through the normal host shutdown mechanism. Systemd stops host services and Docker stops the containers; Kerrigan containers have a 60-second stop grace period before Docker may force termination. This is a bounded service shutdown, not a promise that arbitrary device workloads or long-running jobs will complete.

Runtime requirements and status

Both the controller software and Ubuntu host package must support the power API. Updating only the container is insufficient. Unsupported or unavailable host runtimes leave the controls disabled. The container communicates over the existing host updater socket; it does not need additional privileges.

The host persists the operation, requesting user, request time, and status. A scheduled request survives an updater restart. After a later host boot, status becomes boot_observed; this records the new boot, not proof of how the previous shutdown completed. A host command failure is recorded as failed. A request left in requesting has an uncertain outcome and blocks another power request; inspect the host's shutdown schedule before recovery. The host power status is available at GET /v1/kerrigan/power/status; admins submit {"operation": "shutdown"} or {"operation": "reboot"} to POST /v1/kerrigan/power, which returns HTTP 202 on acceptance.

The same reboot path is available through MQTT as kerrigan.reboot, with kerrigan.power.status for read-only status. See the MQTT Control API for target validation, command envelopes, and retry semantics.