Pull Request

Closes #14404

What? (description)

stopServices ends with

return conditions.WaitForAll(stoppedConds...).Wait(ctx)

on the caller's context — internal/app/machined/pkg/system/system.go#L408. The 30 s deadline declared earlier in the same function, #L381-L383, is shutdownCtx, and it is used only for allDeps.Wait(shutdownCtx) at #L398 — the wait for each service's reverse dependencies. The final wait, for the services themselves, has no deadline, and the callers on this path do not supply one: v1alpha1_controller.go contains neither context.WithTimeout nor context.WithDeadline, and runTask passes the sequence context straight through.

The first commit names the timeout the function already declares (stopServicesTimeout, still 30 s) and applies it to the final wait as well as the reverse-dependency wait. On expiry it logs which services did not stop and returns, so the sequence carries on to unmount the filesystems and power the machine off. A cancellation that comes from the caller is still returned as an error, so Stop and StopWithRevDepenencies keep reporting a genuine cancellation to their callers.

Deliberately, the expiry is not propagated as a task error: a task error aborts the sequence in Controller.run, which would leave the node up just as surely as the hang did. Powering the machine off matters more than stopping every service cleanly.

One point for reviewers: 30 s is the number the function already chose, and reusing it keeps the diff to what the bug requires. It does now bound the whole call rather than the final wait alone, so a stop that legitimately needs longer than 30 s in total will be cut short — with its services named in the log. If you would rather give the final wait its own, larger budget (the per-service worst case is around 45 s: GracefulShutdownTimeout plus killWaitTimeout), that is a one-line change and I am happy to make it.

The second commit, feat: add a force mode to shutdown, mirroring reboot's, adds ShutdownRequest.Mode with the same shape as RebootRequest.Mode, so that talosctl shutdown -m force powers a node off without stopping its services first, exactly as talosctl reboot -m force already reboots without stopping them (#11782, #12049). talosctl shutdown's existing --force skips the cordon/drain, not the service stop, so an operator facing a node whose services will not stop had nothing to reach for. The generated protobuf code was regenerated with the repository's own buf configuration; I confirmed it reproduces the checked-in files byte-identically before making the change. Happy to split that into its own pull request if you would rather take the fix on its own.

Why? (reasoning)

A single service that does not stop blocks the shutdown sequence indefinitely. What is lost is everything after stopServices in stopAllPhaselist — umount, unmountBind, unmountPromotable, unmountSystem, volumeFinalize, stopEverything and the power-off task, v1alpha1_sequencer.go#L509-L557. The machine stays up with its filesystems mounted until someone removes power.

I hit this on a bare-metal node running KubeVirt: the containerd shim backing a VirtualMachineInstance would not go away, cri could not be stopped, and talosctl shutdown never completed.

Every neighbouring wait on the same path is already bounded — stopAndRemoveAllPods caps its CRI work at three minutes (#L929), the process runner escalates to SIGKILL after GracefulShutdownTimeout (process.go#L487), and the containerd runner bounds the post-SIGKILL reap at killWaitTimeout (containerd.go#L347-L354), whose comment states the principle this change applies one level up. That is what makes this one call stand out.

Tests

internal/app/machined/pkg/system/shutdown_bounded_test.go starts a service whose runner does not return when its context is cancelled — the stand-in for a shim that will not die — and asserts that Shutdown returns. It fails on main after its own 40 s deadline and passes with the fix, taking the 30 s bound:

--- FAIL: TestSystemServicesSuite/TestShutdownBoundedWithStuckService (40.04s)
        Error:      Shutdown did not return
        Messages:   still stopping services after 40s; a service which does not stop blocks the shutdown sequence forever

--- PASS: TestSystemServicesSuite/TestShutdownBoundedWithStuckService (30.07s)
    gave up waiting for stuck-shim to stop after 30s, continuing

It waits out a real clock in both directions, which is unavoidable for a missing-deadline bug, so it skips under -short.

A standalone two-pass reproducer that applies only the production part of the change to a clean checkout and reverts it afterwards is attached to the issue, and was rerun today against main at 7f5327d with Go 1.26.8: unpatched FAIL, patched PASS, checkout restored.

go build ./... passes on the branch; gofmt -l is silent and go vet is clean for internal/app/machined/pkg/system/..., internal/app/machined/pkg/runtime/v1alpha1/..., cmd/talosctl/... and pkg/machinery/client/....

Acceptance

Please use the following checklist:

• you linked an issue (if applicable)
• you included tests (if applicable)
• you ran conformance (make conformance)
• you formatted your code (make fmt)
• you linted your code (make lint)
• you generated documentation (make docs)
• you ran unit-tests (make unit-tests)

Rather than tick boxes for targets I did not run, here is exactly what was run, in golang:1.26.8 under Docker with GOFLAGS=-mod=readonly (go.mod and go.sum untouched):

• go build ./... — passes.
• gofmt -l over internal/app/machined/pkg/system/, internal/app/machined/pkg/runtime/v1alpha1/, cmd/talosctl/cmd/talos/ and pkg/machinery/client/ — silent.
• go vet ./internal/app/machined/pkg/system/... ./internal/app/machined/pkg/runtime/v1alpha1/... ./cmd/talosctl/... and go vet ./client/... in pkg/machinery — clean.
• go test ./internal/app/machined/pkg/system/ -run TestSystemServicesSuite/TestShutdownBoundedWithStuckService — the two-pass result quoted above.
• conform enforce from ghcr.io/siderolabs/conform:latest, the image make conformance uses — DCO, conventional commit, header length, header case, header last character, imperative mood, spellcheck, commit body and the license file header all pass. GPG Identity fails, as it does on every contribution from outside the siderolabs organisation, because the keyring it verifies against is the organisation's.

Not run: make lint in full (golangci-lint, vulncheck, deadcode, protobuf and markdown linters), make unit-tests, make docs, and any target that builds a Talos image. The website/content/v1.15/reference/ changes in the branch were generated when the commit was made, not regenerated today.

Disclosure

I used Claude (Anthropic) as an assistant while investigating this and preparing the patch; I have reviewed and tested everything I am submitting, and I take responsibility for it.