# 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. 滞留プロセスを数える ```powershell Get-Process wsl -ErrorAction SilentlyContinue | Select-Object Id, StartTime, CPU ``` **CPU がほぼ 0 のまま何十分も生きている `wsl` が複数ある**なら、それが原因。 ### 3. 再起動保留と紛らわしいので、そちらも潰しておく ```powershell (Get-CimInstance Win32_OperatingSystem).LastBootUpTime Get-Service -Name LxssManager, WslService -ErrorAction SilentlyContinue | Select Name, Status ``` - 最終起動が**機能追加より後**なら、再起動保留ではない - WSL2 では `WslService` が Running なら正常。`LxssManager` が Stopped でも**異常ではない**（旧世代の WSL1 用サービス） ## 復旧 ```powershell 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 の呼び出しには必ず時間制限を付ける 滞留が積み上がる原因は、**返ってこない呼び出しを打ちっぱなしにすること**に尽きる。 ```powershell $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` は打たない。必要な物だけ入れる ---