WSL が「ディストリが無い」ように見える時、疑うのは導入状態ではなく滞留プロセス

Windows 上のエージェントから WSL 経由で CLI を動かしていると、ある日突然すべてが無反応になる。 このとき 「WSL が入っていない」「ディストリが消えた」「再起動が要る」と誤診しやすい。 実際には導入済みで、wsl.exe クライアントが溜まって詰まっているだけのことがある。 この巻物は、その切り分けと復旧、そして再発を止める呼び出し方をまとめる。

症状（この形なら当てはまる）

• wsl --status と wsl -l -v は即座に正しく答える（ディストリ名もバージョンも出る）
• wsl -e <任意のコマンド> が返ってこない（数分待っても無反応）
• wsl --shutdown すら返ってこない
• タスクは「成功」を返しているのに、WSL 内で動くはずの処理のログが1行も出ていない

なぜ誤診するのか（ここが本質）

WSL のコマンドは2種類あり、詰まった時の見え方が非対称になる。

種類	例	詰まった時
レジストリを読むだけ	wsl --status / wsl -l -v / wsl -l -q	即答する
仮想マシンに到達する	wsl -e ... / wsl -d <名> -- ... / wsl --shutdown	無限にハングする

前者だけ見ると「WSL は生きている」と読める。後者だけ見ると「ディストリが無い」と読める。 どちらも間違い。 判定は必ず後者の実行可否で行う。

さらに厄介なのは、この状態で無制限に wsl を呼び続けると滞留がどんどん増えることだ。 エージェントが自動でリトライすると、10件、20件と積み上がって症状が悪化する。

切り分け手順

1. 実行できるかを直接見る（一覧の有無で判断しない）

wsl -e /bin/echo OK

OK が返れば正常。返らなければ以下へ進む。

2. 滞留プロセスを数える

Get-Process wsl -ErrorAction SilentlyContinue | Select-Object Id, StartTime, CPU

CPU がほぼ 0 のまま何十分も生きている wsl が複数あるなら、それが原因。

3. 再起動保留と紛らわしいので、そちらも潰しておく

(Get-CimInstance Win32_OperatingSystem).LastBootUpTime
Get-Service -Name LxssManager, WslService -ErrorAction SilentlyContinue | Select Name, Status

• 最終起動が機能追加より後なら、再起動保留ではない
• WSL2 では WslService が Running なら正常。LxssManager が Stopped でも異常ではない（旧世代の WSL1 用サービス）

復旧

Get-Process wsl | Stop-Process -Force
Start-Sleep -Seconds 3
wsl --shutdown
wsl -e /bin/echo OK

⚠️ 落とすのは wsl.exe だけ。 bash プロセスは落とさないこと。 同じマシンで動いている別のシェルやエージェントのセッションが混ざっている可能性がある。 vmmem や WSL のサービス本体も落とさない（wsl --shutdown が正規の手順）。

再発防止: WSL の呼び出しには必ず時間制限を付ける

滞留が積み上がる原因は、返ってこない呼び出しを打ちっぱなしにすることに尽きる。

$j = Start-Job { wsl -e bash -c "<コマンド>" 2>&1 }
if (Wait-Job $j -Timeout 120) { Receive-Job $j } else { "タイムアウト"; Stop-Job $j }
Remove-Job $j -Force

• エージェントに自動リトライさせる場合、リトライ前に滞留数を確認させる
• タイムアウトした呼び出しは必ず Stop-Job で始末する

詰まりが取れた後に残っていた「本当の障害」

滞留を解消しても目的の CLI が動かないことがある。PATH interop の罠が典型。

$ wsl -e bash -c "command -v node; command -v npm; command -v <対象CLI>"
（node は出ない）
/mnt/c/Program Files/nodejs/npm
/mnt/c/Users/<ユーザー>/AppData/Roaming/npm/<対象CLI>

/mnt/c/... に解決されているものは Windows 側の実体で、Linux では動かない。 Linux ネイティブを入れ直す必要がある。

export DEBIAN_FRONTEND=noninteractive
apt-get update
apt-get install -y ca-certificates curl gnupg
curl -fsSL https://deb.nodesource.com/setup_22.x | bash -
apt-get install -y nodejs
npm install -g <対象パッケージ>

導入後は解決順を確認する。ここを見ずに「入れた」で終わらせない。

$ wsl -e bash -c "which -a <対象CLI>"
/usr/bin/<対象CLI>          ← Linux 側が先頭なら正しい
/bin/<対象CLI>
/mnt/c/Users/.../npm/<対象CLI>   ← Windows 側が残っていても、後ろなら実害なし

落とし穴のまとめ

• 「一覧が引ける＝生きている」ではない。 実行してみるまで分からない
• 「実行できない＝入っていない」でもない。 滞留を先に疑う
• 終了コード 0 は、その処理が走った証拠にならない。 ログに該当ステップの行が出ているかで見る
• タスクスケジューラが参照するスクリプトの更新時刻を見る。実行時刻より後に更新されていれば、その回は旧版で走っている
• apt upgrade は打たない。必要な物だけ入れる