majorlinux bc4ff144df wiki: add Ansible reboot.yml become-timeout-on-WSL2 troubleshooting article

Documents why WSL2 hosts fail an Ansible reboot play at privilege
escalation (Timeout waiting for privilege escalation prompt) — WSL2 has
no real reboot semantics + become stalls over the Windows OpenSSH->WSL2
bridge — and the fix: scope reboot.yml to hosts: all:!wsl. Registered
in SUMMARY.md and 05-troubleshooting/index.md.

2026-06-12 03:57:17 -04:00

4.1 KiB

Raw Blame History

title

domain

Ansible reboot.yml: become Timeout on WSL2 Hosts (Exclude Them)

Problem

Running a reboot play across a Fedora fleet that includes a WSL2 "host" fails on the WSL2 box at privilege escalation — before the reboot command ever runs:

$ ansible-playbook reboot.yml --limit fedora

TASK [Reboot the server] *******************************************************
changed: [majorhome]
changed: [majorlab]
changed: [majormail]
changed: [majordiscord]
[ERROR]: Task failed: Action failed: Timeout (62s) waiting for privilege
escalation prompt:
fatal: [majorrig-wsl]: FAILED! => {"changed": false,
  "msg": "Timeout (62s) waiting for privilege escalation prompt:",
  "reboot": false}

Every real server reboots fine. Only the WSL2 host fails, and "reboot": false confirms the shutdown command never executed.

Cause

Two independent problems, either of which is enough to break a reboot play against WSL2:

WSL2 has no real reboot semantics. ansible.builtin.reboot issues a shutdown, then blocks up to reboot_timeout (e.g. 900s) waiting for SSH to come back. A WSL2 distro doesn't reboot — it just terminates, and nothing relaunches it automatically. The task would hang the full timeout and then fail.
become times out over the Windows OpenSSH → WSL2 bridge. When a WSL2 box is reached as majorlinux@host through Windows' built-in OpenSSH Server (which forwards into WSL via the default shell), Ansible's privilege-escalation handshake watches the SSH stream for the sudo prompt/success marker. Across the Windows-intercept pty, that marker detection stalls until the 62s timeout. This happens even with passwordless sudo — NOPASSWD is configured and correct; Ansible simply never sees the handshake complete.

The error surfaces as #2 (it fails at escalation first), but #1 is the deeper reason WSL2 doesn't belong in a reboot play at all.

Solution

Exclude the WSL group from the reboot play. A WSL2 instance is a managed workstation environment, not a server — it belongs in package/update plays but not in server lifecycle operations like reboot.

Scope the play to exclude the wsl group so even a broad --limit skips it:

# reboot.yml
- name: Reboot servers
  hosts: all:!wsl     # was: hosts: all
  become: true
  tasks:
    - name: Reboot the server
      ansible.builtin.reboot:
        msg: "Reboot initiated by Ansible"
        reboot_timeout: 900

This assumes your WSL2 hosts are in a dedicated inventory group:

wsl:
  hosts:
    majorrig-wsl:
      ansible_host: 100.98.47.29

Verify the targeting before running — the WSL host should be gone:

$ ansible-playbook reboot.yml --limit fedora --list-hosts
  play #1 (all:!wsl): Reboot servers
    hosts (4):
      majorhome
      majorlab
      majordiscord
      majormail

Rebooting the WSL2 instance itself

When you genuinely need to "reboot" WSL2, do it from the Windows side — not Ansible:

wsl --shutdown

The distro relaunches on next access (next SSH login or wsl invocation). WSL2 stays in update.yml (dnf upgrades) and other package plays; it's only excluded from reboot and other server-specific roles.

Why not just fix the become timeout?

You could raise timeout or tweak the become flow, but it doesn't address problem #1 — even a successful escalation would leave the reboot task hanging the full reboot_timeout because WSL2 never comes back the way the module expects. Excluding WSL from server lifecycle plays is the correct fix, not a workaround.

4.1 KiB Raw Blame History