ENGINE-1383 winrm fixes for reboot and panic resolve.

[james-nesbitt]

Hey K0s team. I have been battling some windows/winrm issues in Launchpad, and with some Claude help have discovered:

1. windows 2019 (in particular) doesn't like the windows Reboot() function, which doesn't always work.
2. the winrm close panic still needs a different approach to resolve a race condition.

In this PR are two fixes:

1. The new reboot switches a flat "shutdown" Exec() to using "schtasks" to run a shutdown. The effort get's more complicated after CoPilot pointed out that you have to be careful with the schtask removal, as you may end up in a persistant reboot. I will take another stab at simplifying it (I think that there is a --once flag for schtasks.)

2. Drops the panic recover() and focuses on race resolution in closing the command Stdout/Stderr in two different places.

[james-nesbitt]

The double-close race in Exec()

The close of closed channel panic originates from two independent Close() calls racing against defer command.Close() in winrm.go's Exec()
function.

First close — inside the stdout goroutine (~line 341 pre-fix):

  if execOpts.Writer == nil {
      outputScanner := bufio.NewScanner(command.Stdout)
      for outputScanner.Scan() { ... }
      // ...
      command.Stdout.Close()   // ← first close of Stdout
  }

Second close — inside the stderr goroutine (~line 373 pre-fix):

  outputScanner := bufio.NewScanner(command.Stderr)
  for outputScanner.Scan() { ... }
  // ...
  command.Stderr.Close()   // ← first close of Stderr

Third close — deferred on the function itself (~line 308):

  command, err := shell.ExecuteWithContext(context.Background(), cmd)
  // ...
  defer command.Close()   // ← closes Stdout and Stderr again on function return

The race sequence:

1. Stdout goroutine finishes scanning → calls command.Stdout.Close()
2. Stderr goroutine finishes scanning → calls command.Stderr.Close()
3. wg.Wait() returns (both goroutines done)
4. command.Wait() is called
5. Function returns → defer command.Close() fires, closing Stdout and Stderr a second time → close of closed channel panic

With a single WinRM connection the timing rarely overlapped. With 6 concurrent WinRM connections all finishing waitForHost polling
simultaneously (reproduced by running launchpad against a cluster with 2× each of Windows Server 2019, 2022, 2025), the race fired
consistently and caused the process to terminate silently after the recovered panics left goroutine state degraded.

The fix removes the explicit command.Stdout.Close() and command.Stderr.Close() calls from both goroutines. The masterzen/winrm library
closes the pipes when the WinRM protocol signals command completion, so the scanner loops reach EOF and exit cleanly without any explicit
close. defer command.Close() remains as the sole cleanup path. The recover() workarounds in both goroutines and in Command.Wait() are
then no longer needed and are removed.

[Copilot]

Pull request overview

This PR addresses Windows/WinRM reliability issues in rig by changing how Windows reboots are triggered under WinRM and by adjusting WinRM command stream handling to avoid race-related panics during close.

Changes:

• Reworked Windows Reboot() to create/run a SYSTEM scheduled task that triggers shutdown /r /f /t 5, then attempts immediate cleanup.
• Removed panic-recovery logic and adjusted WinRM Exec() stream readers to avoid closing stdout/stderr in multiple places.
• Simplified Command.Wait() error returns.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File	Description
winrm.go	Removes panic-recovery and adjusts close/return flow for WinRM command execution.
os/windows.go	Implements reboot via schtasks running as SYSTEM and adds documentation around the approach.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Using a fixed scheduled task name ("RigReboot") with /f can overwrite an existing task with the same name and may conflict with concurrent reboot attempts. Consider generating a unique task name per invocation (e.g., include a timestamp/UUID) and/or checking for an existing task before overwriting/deleting.

[Copilot]

Delete failures are fully ignored, but with /sc onstart a leftover task will reboot the machine on every subsequent startup (persistent reboot loop). This is a high-risk failure mode. Prefer making the task self-cleaning (e.g., include a delete/disable step in the task action) and/or use a schedule that cannot retrigger on startup (e.g., /sc once with stderr tolerated via exec.AllowWinStderr()), and only ignore delete errors that are clearly caused by the ongoing reboot/connection drop.

[Copilot]

time.Sleep(15 * time.Second) is a hard-coded delay that is decoupled from the configured shutdown timer (/t 5). Consider deriving this from the shutdown delay (plus a small buffer) or documenting why 15s is required, to avoid unnecessary slowdowns and make future changes safer.

[Copilot]

The doc comment for Command.Wait is duplicated ("Wait blocks until the command finishes" appears twice). Please remove the extra line to keep godoc clean.

Suggested change

// Wait blocks until the command finishes

[Copilot]

This comment calls the scheduled task "one-shot", but the implementation uses schtasks /sc onstart, which will run on every startup unless the task is successfully deleted. Either adjust the wording to reflect that it's an ONSTART task deleted as part of the reboot flow, or switch to a truly one-shot schedule (e.g., /sc once) if feasible.