majorlinux
bc4ff144df
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.
103 lines
4.1 KiB
Markdown
103 lines
4.1 KiB
Markdown
---
|
|
title: "Ansible reboot.yml: become Timeout on WSL2 Hosts (Exclude Them)"
|
|
domain: troubleshooting
|
|
category: ansible
|
|
tags: [ansible, wsl, wsl2, windows, reboot, become, privilege-escalation, openssh, inventory]
|
|
status: published
|
|
created: 2026-06-12
|
|
updated: 2026-06-12
|
|
---
|
|
|
|
# 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:
|
|
|
|
```console
|
|
$ 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:
|
|
|
|
1. **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.
|
|
|
|
2. **`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:
|
|
|
|
```yaml
|
|
# 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:
|
|
|
|
```yaml
|
|
wsl:
|
|
hosts:
|
|
majorrig-wsl:
|
|
ansible_host: 100.98.47.29
|
|
```
|
|
|
|
Verify the targeting before running — the WSL host should be gone:
|
|
|
|
```console
|
|
$ 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:
|
|
|
|
```powershell
|
|
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.
|
|
|
|
## Related
|
|
|
|
- [Ansible: ansible.cfg Ignored on WSL2 Windows Mounts](ansible-wsl2-world-writable-mount-ignores-cfg.md)
|
|
- [Windows OpenSSH: WSL Default Shell Breaks Remote Commands](networking/windows-openssh-wsl-default-shell-breaks-remote-commands.md)
|
|
- [Ansible: SSH Timeout During dnf upgrade on Fedora Hosts](ansible-ssh-timeout-dnf-upgrade.md)
|
|
</content>
|
|
</invoke>
|