WinSCM.StartService fails on slow/cold start: benign StartPending warning trips ErrWroteStderr

[vikramhh]

Environment

• rig/v2 v2.1.0
• Windows target (WinSCM init system)

Summary

Starting a Windows service that does not become Running instantaneously fails, even though the service starts successfully. The returned error is:

failed to start service <name>: command wrote output to stderr (#Waiting for service '<display name>' to start...)

Root cause

WinSCM.StartService runs Start-Service without suppressing the warning stream and without AllowWinStderr:

func (c WinSCM) StartService(ctx context.Context, h cmd.ContextRunner, s string) error {
    if err := h.ExecContext(ctx, "$ErrorActionPreference='Stop'\nStart-Service "+ps.SingleQuote(s)+" -ErrorAction Stop", cmd.PS()); err != nil {
        return fmt.Errorf("failed to start service %s: %w", s, err)
    }
    return nil
}

When the target service stays in StartPending for more than a moment (common on a cold first start — the service does real initialization work), PowerShell's Start-Service emits a non-terminating warning to the warning stream:

WARNING: Waiting for service '<display> (<name>)' to start...

Run as a subprocess, the warning stream is written to stderr. rig treats any stderr output from a Windows command as a failure (cmd.ErrWroteStderr, "command wrote output to stderr") unless AllowWinStderr is set. So a successful-but-slow start is reported as an error. StopService/RestartService have the same shape (StopPending warning).

The command exits 0 and the service does reach Running; only the benign warning on stderr causes the false failure.

Proposed fix

Add -WarningAction SilentlyContinue to the Start-Service/Stop-Service/Restart-Service commands in WinSCM (and/or set AllowWinStderr on these ExecContext calls). Genuine failures still surface via -ErrorAction Stop (terminating error → non-zero exit), so error detection is preserved; only the benign progress warning is silenced.

"$ErrorActionPreference='Stop'\nStart-Service "+ps.SingleQuote(s)+" -ErrorAction Stop -WarningAction SilentlyContinue"

Happy to open a PR.

[kke]

Confirmed against initsystem/winscm.go in v2.1.0 — the analysis is correct. StartService/StopService/RestartService all run the bare cmdlet with only -ErrorAction Stop, and the executor fails any Windows command that writes to stderr unless AllowWinStderr is set (cmd/executor.go:243). Start-Service/Stop-Service write the "Waiting for service '…' to start/stop…" progress message to the warning stream, which lands on stderr under a subprocess → false failure on a slow/cold start.

The fix is good. One refinement, since you offered "and/or": please go with -WarningAction SilentlyContinue only, and not AllowWinStderr. -WarningAction silences exactly the benign progress warning while -ErrorAction Stop still turns a genuine start failure into a terminating error (non-zero exit), so real error detection is preserved. AllowWinStderr is a blunt instrument that would greenlight any stderr output and could mask unexpected diagnostics — no reason to widen the net when -WarningAction targets precisely the message in question.

Rig has been considering any output to stderr on windows as an error condition because that's MOSTLY true on windows, while the exit status has been a pretty unreliable way to detect if a command succeeded or not on Windows, that's why there's the AllowWinStderr in the first place.