気づくと vmmem が数 GB になってる
WSL は割り当てメモリ上限を指定できるので小さめにしておけばいいのだけど ときどき大きめのメモリが必要になるので上限は余裕を持たせておきたいのですよね
通常時はメモリを使って無くても Linux 側でキャッシュとして確保されたものも Windows からすると使用中として扱われて使用メモリが増えます

root@WIN-NOTE:~# free -h
               total        used        free      shared  buff/cache   available
Mem:           6.1Gi       139Mi       4.8Gi       0.0Ki       1.2Gi       5.8Gi
Swap:          2.0Gi          0B       2.0Gi

buff/cache のところ

解放するために手動でキャッシュをクリアします

root@WIN-NOTE:~# echo 3 > /proc/sys/vm/drop_caches
root@WIN-NOTE:~# free -h
               total        used        free      shared  buff/cache   available
Mem:           6.1Gi       135Mi       5.9Gi       0.0Ki       110Mi       5.8Gi
Swap:          2.0Gi          0B       2.0Gi

/proc/sys/vm/drop_caches に 3 を書き込むとクリアしてくれます (root 権限が必要)

こうすると Windows 側の vmmem の使用量も小さくなります
一気に下がるんじゃなくて時間をおいて段階的に下がる感じ
完全に used + buff/cache の値まで下がらず多少余裕を持って確保されてるみたい
上の状況だと 1GB 以上あったものが 700MB くらいまで減少

以前 WSL2.0 の新機能で自動でキャッシュを解放して Windows に戻してくれる機能が追加されるとか話がありましたがまだデフォルトで有効にはなってないみたいですね

久々に使った PC で AlmaLinux9 の WSL を起動したらこんなエラーメッセージが出て動かせませんでした

Installing, this may take a few minutes...
WslRegisterDistribution failed with error: 0x80070050
Error: 0x80070050 ??????????

Press any key to continue...

WSL の更新や再起動でも変わらないです
Ubuntu の方は問題なく動いてます

wsl コマンドだとどうかなと 「wsl -d almalinux9」 を実行すると動きました
Windows アプリのショートカットがおかしくなったみたいです

そのアプリから開く必要は特にないので ショートカットを新しく作りました
右クリックメニューのショートカットの作成で項目の場所に

wsl -d almalinux9

ショートカット名を 「AlmaLinux9」
として作るだけです

ショートカットのダブルクリックで起動します

今回問題が起きた環境は WindowsTerminal が入ってないので確認できてないですが VSCode からディストリビューションを選択する方法だと問題なかったので アプリのショートカットを通さず ディストリビューション一覧を取得してディストリビューション名で起動するところは問題なさそうです

なにかを試すときに一時的なコンテナを作ってそこで作業してることがよくあります
そこで作ったものを Windows 側で使いたいなんてことがときどきあります
Windows 側とまで行かなくてもホスト側の WSL に持ってきたいこともあります
また逆に Windows 側で用意したファイルをコンテナで使いたかったりします

それを見越して とりあえずで docker run するときにカレントディレクトリをコンテナの /mnt にマウントするようにしてるのですが 時々忘れます
そして忘れたときに限ってコピーしたくなったりするものです
コンテナを作り直してもいいのですが 色々パッケージをインストールしたり 環境の設定を変えたりしているともう一度やり直しは面倒です
その時点のコンテナをイメージ化してそこからコンテナを作るという方法もとれますが 一時的なもののためにイメージ化するのも面倒です
それならコンテナを作り直しでもいいかなと思うくらい

ただやっぱり面倒なのでいい方法がないかなと考えていてふと思いつきました
WSL で sshd サーバーを起動しよう
コンテナから WSL には通信できるので scp でコピーできます
やってみると簡単にできました

sudo apt install openssh-server
sudo service ssh start

という感じです
sshd が入ってなければ sshd のインストールとサービスの起動をします
あとはコンテナから

scp file.txt user@172.21.76.78:

みたいな感じに使います

user は WSL のユーザー名で 172.21.76.78 は WSL の IP アドレスです

WSL まで持ってきたら Windows からは \\wsl$\... のフォルダでアクセスできるので扱いやすいです

---

以前使ってた方法

◯ http

ウェブサーバーを起動して GET/POST で通信してました
ウェブサーバーは扱いやすいですし GET だけなら python3 がデフォルトで入ってるので http.server モジュールの起動だけで使えるなど楽でした
しかし POST で保存するとなると面倒ですし GET に揃えると送りたい側でサーバーを起動しないといけないです
また フォルダをコピーしたいときには zip 化するなど一手間が必要でした
コンテナ環境だと zip の操作コマンドも入ってなかったりしますし

◯ cifs mount

フォルダのコピーなら共有フォルダがあると便利です
ただ Linux の cifs マウントって結構面倒ですし 頻繁にセットアップ時にうまく行かなくてググってます
オプションも覚えづらくて毎回ググる必要があります

Windows と Docker コンテナ間が直接通信できたらこれでもいいのですが ネットワークが違うので Windows ←→ WSL と WSL ←→ コンテナでしか通信できないです
それなら ssh を通して scp 等のコピーのほうが手軽だと思います

---

書いた後で思い出しましたが そういえば docker コマンド内にも cp みたいなのがあった気がします
コンテナ内からのコマンドで実行できませんが もうひとつ WSL ウィンドウを開いてホスト側から操作する場合はこっちでもいいかもしれません

https://github.com/microsoft/WSL/releases/tag/2.0.9

9 月にプレリリースという形でリリースされていた 2.0 が正式リリースされました
2.0.9 です

メモリやストレージを自動で解放してくれたり 外部端末から IP 指定でアクセスしても WSL にアクセスできない問題を解決したり色々新機能がありますね
新機能がまとめられてる記事↓
https://www.publickey1.jp/blog/23/windows_subsystem_for_linuxwsllanwsl.html

特にネットワーク周りの問題は面倒が多かったですからね
ただ Docker 周りでまだ問題があるとかいう話も聞きます
仮想マシンという形で動作してる以上 仕方ない部分もありそうですね

ただ せっかく仮想マシンで分かれてるんだし ブリッジ接続にしてくれたほうが便利だと思ったりもします
複数の WSL ディストリビューションや WSL 内の Docker/Podman コンテナで同時にウェブサーバーを起動してることってけっこうあります
全部をホストの Windows で動作してるようにみせかけるとポートの競合が起きて面倒です
全部 3000 番に揃えることができず それぞれのポートを別にしないといけないです
その点ブリッジだとアクセスする IP アドレスが違うのでポートの競合は気にしなくていいです

WSL 内の Docker を Windows と同じ階層にあるように見せて↓みたいなことができるかは知らないですけど

Windows        192.168.10.11
  WSL(1)       192.168.10.21
    Docker(1)  192.168.10.22
    Docker(2)  192.168.10.23
  WSL(2)       192.168.10.31
    Docker(1)  192.168.10.32
    Docker(2)  192.168.10.33

VSCode の拡張機能で WSL と接続できます
接続すると そのウィンドウは WSL 用に開き直されますが まだフォルダを開いた状態にはなっていません
フォルダを開いたら あとは Windows のときと同じようにサイドバーからファイルを選んで編集できます

特定のフォルダを開かずに WSL 内のファイルを編集したいときはフォルダを開かずそのまま使えます
Ctrl-O や File > Open File でファイルを開こうとすると Windows のダイアログのかわりにコマンドメニューが表示されます
ここでパスを指定することでファイルを開けます

ですが あまりこの方法は使いやすくないです
WSL なのでコマンドラインから操作したいです

そういうときは Ctrl-@ でターミナルを開きます
WSL に接続してると PowerShell の代わりに WSL のシェルが起動します
ここで

code foo.txt

のように code コマンドを実行すると VSCode のタブで開いてくれます
ファイルがなければ新規作成されます
nano や micro など WSL 内のエディタを開く感じで VSCode でファイルを編集できます

なんらかのコマンドの出力結果を VSCode で編集したり確認したりしたいなら code コマンドのパラメータに 「-」 を指定することで標準入力を受け取れます

apt list --installed | code -

のようにできます

かなり便利なので Windows Terminal で WSL は開かずに VSCode だけで十分かもしれません

環境はストア版 WSL (Ubuntu) で systemd から Docker を起動します
インストール直後はなんの問題もなく docker-ce をインストールして systemd から起動するだけで普通に使えていたのですが 強制終了されてから動かなくなりました
再起動の原因はストア版 WSL が勝手に更新されること
更新時にそのアプリが終了されるので WSL が実行中だと強制終了されてしまいます
その後に WSL を起動して Docker を使おうとすると動きません

docker コマンドを実行して docker サーバーと通信しそうなところで反応がなくてずっと応答が返ってこない状態です
systemctl status で見てみると inactive らしいですが ランプは緑色でよくわからない状態です
停止してみようにも失敗します
sock ファイルのせいでアクティブなままになってるみたいな警告が出てました
sock ファイルは残ってたので削除して containerd も停止してから再起動してみました
これでも解決しません
WSL ごと停止して再起動してみても同じ状況になります
sock ファイルは再度作られていて journalctl でログを見ると 一旦起動してすぐ終了してる感じです

この現象はこれまでも数回起きていて docker を再インストールすれば直ってます
アップデートでもパッケージを入れ直すことになるみたいなので アップデートでもいいです
発生頻度は数ヶ月に 1 回で その頃には更新があることも多いのでアップデートで対処してることが多いです

はっきりした原因がわからないのが気持ち悪いですが とりあえずの対処方法はわかるので今のところこれで対処してます
ただ今回はアップデートで直ったものの docker-ce は更新対象に含まれてなかったです
containerd は含まれていたのでこっちが原因なのかもしれないですが containerd は再起動後も問題なく動いていて stop/start でもエラーもなかったです

少し気になってるのはストア WSL の更新で強制終了してるというところです
「wsl --shutdown」 で強制停止は何度かあるはずですが このときは Docker に問題が起きてない気がします
WSL 自体の更新のせいでコンテナの仕組みに影響してる ということもありえるのでしょうか
再インストールすれば最新版に更新されますし アップデートでその変更に対処してるのかもしれません
ストア版にしてから発生というのも ストア版になるまでは WSL 自体の更新はほぼなかったので気づかなかっただけなのかもです

結構ありえるかもと思ってみたものの アップデートしないとコンテナが動かなくなるような変更を何度もするかという疑問がありますし 変更履歴を簡単にみても WSL 対応みたいなのはなかったです

---

その後 また同じ状態が発生しました
ただ今回は前と違って containerd が停止しています
起動しようとしても反応がなく 1 分程度待っても終わりません
起動コマンドは強制終了して再インストールを試しました
期間が短いこともあって containerd も docker-ce も最新版で apt のアップデートはなかったので再インストールです
しかし インストール直後のセットアップ処理で起動しようとするからか containerd のセットアップで固まったままになります
強制終了して何度か試しても同じ結果です

固まった状態で CPU の使用率や IO の負荷を見ても特に負荷が高いわけでもなく 何もしてない待機状態みたいです
事前に起動しないといけないサーバーとかはないと思うのですけど
WSL 自体の再起動も試しましたが変わりません

処理が重たくて時間がかかってるわけじゃないなら なにかの対処をしないと改善しなさそうだけど 原因が見当たらないです
半分あきらめて 固まったまま放置していて 数十分後に見てみるとなぜかコマンドが完了していました
containerd のステータスを見ると起動しています
docker も問題なく起動できました

やっぱり原因は不明ですが containerd の起動で進まないならしばらくそのまま放置で起動できる場合もあるようです

いつのまにかエクスプローラーのサイドバーに 「Linux」 という項目が増えてました
普段 「クイックアクセス」 や 「PC」 の部分が見えていて 下の方にスクロールしないので全然気づいてませんでした

この 「Linux」 を開くと WSL のディストリビューション一覧が共有という形で見れます
ディストリビューションを選ぶとそのディストリビューションのルートディレクトリが表示されます

これまでアドレスバーに 「\\wsl$」 と入力してから開いていた場所と同じような動きです
「Linux」 からフォルダを開いてからアドレスバーでパスを取得するとこうなってました

\\wsl.localhost\Ubuntu-22.04

wsl.localhost というサーバー名になってるようです
自分で 「\\wsl$」 と入力したり そこへのショートカットをつくる手間が省けるので便利です

最近 WSL 1.0 がリリースされたというニュースをよく見かけました
WSL1 / WSL2 とは別の区分で WSL の仕組み自体のバージョンがあるようで ストア版が 1.0 になったそうです
最初は特に興味もなく ストア版というと勝手にアップデートされて Windows Terminal みたいな問題起きそうとかそういうイメージでした

調べてみると ただインストールの方法が違うだけでなく追加機能が色々あるようです
また これまでの OS 組み込みの方は廃止はされないものの 積極的に開発されるものはストア版のようです
これまでの WSL は WSL1 みたいな扱いになるってことでしょうか

それなら気が向いたときに切り替えておこうかなくらいに考えてましたが systemd が使えるという情報を見つけました
WSL にしても Docker コンテナにしても systemd が使えないのはとても不便だったので これはすごく良さそうです
ということで早速切り替えました

---

やることは KB5020030 をインストールして 「wsl --update」 コマンドを実行するだけです
今のところはこのアップデートは自動インストールされないようで Windows Update の画面でオプションとして並んでいます
これを手動でインストールしてから 「wsl --update」 を実行します
これまで全然カーネルのアップデートをしていないと複数回の実行が必要になることもあるそうです

切り替えが終わると 「wsl --version」 コマンドでバージョンが見れるようになります
古いバージョンだと 「--version」 というオプションはないので無効なオプションというエラーメッセージと使い方の長い説明が表示されます

systemd 機能も今のところはデフォルトで有効になっていないので設定が必要です
ディストリビューション内で 「/etc/wsl.conf」 に↓を追記します
ファイルがなければ作ります

[boot]
systemd=true

WSL を再起動すると systemd が有効になっています

ただ注意しないといけないことがあって すでにインストール済みだったサービスの一部は起動に失敗していると思います
私の場合はたしか apache2 は動作していて postgresql や docker はダメでした
インストール時に systemd がないことでセットアップスクリプトが完了していないのだと思います
そういったパッケージは再インストールすることで正常に動作するようになりました

あと個人的に困ったところは ストア版にすると wsltty が起動しなくなりました
issue はすでにあって 軽く見た感じだと一応対処したリリースは出ていそうですが まだ issue がオープンになってるあたり完全ではないのかもです
https://github.com/mintty/wsltty/issues/302

これを機に WSL も Windows Terminal に移してみようかと試していると意外と不便なところがありました
exit コマンドで終了するとき 引数なしだと最後のコマンドの exit コードを引き継ぐようです
例えば存在しないコマンドを実行したら 127 になっていて そのまま終了するとシェルが 127 のコードで終了します
Windows Terminal はタブのプロセスが正常以外のコードで終了するとタブを閉じてくれません
エラーがあるとわかるという点では良い機能と言えますが 毎回 exit に 0 を指定するのは面倒です

早速入れようとしたけど wsl --install コマンドだと無効なディストリビューションって言われる
ストアにはあるのに
リストを表示すると出てこない

PS C:\windows\system32> wsl --list --online
インストールできる有効なディストリビューションの一覧を次に示します。
既定の分布は ' * ' で表されます。
 'wsl --install -d <Distro>'を使用してインストールします。

  NAME            FRIENDLY NAME
* Ubuntu          Ubuntu
  Debian          Debian GNU/Linux
  kali-linux      Kali Linux Rolling
  openSUSE-42     openSUSE Leap 42
  SLES-12         SUSE Linux Enterprise Server v12
  Ubuntu-16.04    Ubuntu 16.04 LTS
  Ubuntu-18.04    Ubuntu 18.04 LTS
  Ubuntu-20.04    Ubuntu 20.04 LTS

ちょっと前に出た almalinux もないしストアが更新されても WSL 自体が更新されるまでリストは変わらない？

Ubuntu を入れると最新のエイリアスになってて 22.04 が入ることを期待して Ubuntu ディストリビューションを選んだけど インストールされたのは 20.04 だった

今のところはストアから入れるか 20.04 をアップデートしかなさそう

昔は来るとか言われてた Fedora の公式 WSL も来なかったですし 最近はディストリビューションに代わり映えがしない気がします
みんな何使ってるだろうとネットを見てると CentOS だったり ストアにおいてないディストリビューションを使ってるという書き込みもところどころで見かけます
以前でも公式に用意されないディストリビューションを WSL で使うための手順は見かけましたが とても面倒で複雑な方法でそこまでして入れるなら Ubuntu でいいよと思ったほど
しかし 思ったより見かけるのでやり方が簡単になったのかなと調べてみると なんと Docker コンテナのエクスポートデータを WSL にインポートするとかいう驚きの方法
WSL 内でバックアップしたり クローンしたりするために export/import 機能があるのは知っていましたが Docker コンテナのフォーマットと同じとは思いませんでした

WSL の export/import 機能は 昔試したときは謎のエラーで動作しなくて結局使ってませんでしたが どういうフォーマットか気になるのでエクスポートを試してみました

wsl --export Ubuntu export.tar

というコマンドを Windows 側で実行すれば Ubuntu ディストリビューションを export.tar ファイルにエクスポートできます
今回は成功したので tar ファイルの中身を見てみます

一番上の階層は「.」フォルダだけ
「.」フォルダの中に

bin
boot
dev
etc
home
mnt
proc
usr
var

など Linux のルートにあるフォルダが並んでいます
VM で使われる仮想ディスク的な専用のファイルではなく 単純にルートからすべてをファイルとしてエクスポートしてるようです
そんなに使ってないのに 2.4GB もありましたが ファイルを tar でまとめただけだからなんですね
なんとなく 7z に圧縮してみると 850MB になって 35% のサイズになりました
バックアップ用途なら圧縮が効率良さそうです

boot や proc ってどうなってるのと思いましたが中身は空でフォルダだけした
データとして必要な etc や usr などのファイルだけをエクスポートして その他の実行時に使うものは WSL や Docker の各環境で用意するってことなんですかね

エクスポートされたデータは上記の通りで中身だけです
WSL としてのメタデータはなくて バージョンやディストリビューション名もありません
一応 /etc/os-release を見ればディストリビューションの種類の確認はできますけど 中身をみることになります
WSL はバージョンの 1 か 2 で結構違っていますが 設定やプログラムやユーザデータ等をファイルとして export/import するのだと 1 でも 2 でも問題ないのかもしれません
WSL 上のディストリビューション名が含まれてないので 同じディストリビューションで Ubuntu_1, Ubuntu_2, ... のように複数の WSL ディストリビューションを作ることもできます

Docker を使っていて それなりによく使うツールで試したいことがあると毎回準備が面倒でコンテナは使い捨てではなく使いまわしすることが多いので Docker コンテナではなく WSL ディストリビューションとしてしまうのもありかもですね

WSL コマンドの使い方を見たくて

wsl --help

コマンドを実行しました
出力はこんな感じ

Copyright (c) Microsoft Corporation. All rights reserved.

使用法: wsl.exe [Argument] [Options...] [CommandLine]

Linux バイナリを実行するための引数:

    コマンドラインを指定しない場合、既定のシェルが起動され wsl.exe ます。

    --exec、-e <CommandLine>
        既定の Linux シェルを使用せずに、指定したコマンドを実行します。

    --
        残りのコマンドラインをそのまま渡します。

オプション：
    --cd <Directory>
        指定したディレクトリを現在の作業ディレクトリとして設定します。
        ~ が使用されている場合は、Linux ユーザーのホームパスが使用されます。パスが始まる場合
        文字が含まれている場合は、Linux の絶対パスと解釈されます。
        それ以外の場合、この値は Windows の絶対パスである必要があります。

--分布、-d <Distro>
        指定したディストリビューションを実行します。

    --ユーザー、-u <UserName>
        指定されたユーザーとして実行します。

Windows Subsystem for Linux を管理するための引数:

    --ヘルプ
        使用方法に関する情報を表示します。

    --install [Options]
      追加の Windows Subsystem for Linux ディストリビューションをインストールします。
      有効なディストリビューションの一覧を表示するには、'wsl--list--online' を使用してください。

長いので以下略

いくつか気になる部分が

--分布、-d <Distro>
--ユーザー、-u <UserName>
--ヘルプ

え？日本語コマンド使えるの？？

翻訳してはいけないところを翻訳してるだけな気はするけど もしかしたらもありえるし一応試してみる

C:\>wsl --ヘルプ
コマンド ライン オプションが無効です: --ヘルプ

ですよねー
これなら翻訳しないほうがマシだよ

WSL で使っていた Ubuntu が以前のバージョンのままだったのでアップグレードしようとしました
LTS 間でのアップグレードなので問題もないと思っていたのですが問題が起きました

「do-release-upgrade」 コマンドが途中で止まります
最後に表示されるメッセージはこれです

Reading state information... Done

何度試してもここで止まります
ログファイルを見てみてもエラーらしいものが見つかりません

以前に別の PC で Ubuntu を更新したときも同じコマンドを使ったはずで そのときは何も問題なく更新できたと思うのですけどね

ぐぐってみるとこんなページがありました
https://github.com/microsoft/WSL/discussions/3489

snapd を消すと動くという報告があります

apt remove snapd

これを実行してからもう一度 do-release-upgrade コマンドを実行してみます
すると 次に進みました！

上のページでは 18.04 へのアップグレードですが 私は 20.04 へのアップグレードでした
バージョン問わず do-release-upgrade 使う場合に起きる問題のようです

snapd を調べてみると パッケージマネージャでした
そういえば GUI インストールした Ubuntu ではこの折り紙みたいなアイコンを見たことがあります
この WSL 環境では GUI アプリを試しに使ってみたことがあり snapd が入ってたようです
以前問題なく更新できた環境だと GUI を入れてなかったから snapd も入ってなかったのかもしれません

Linux 環境で動きを確認したいところがあって WSL2 内の Docker を使います
ファイルがいくつかあって編集して実行を繰り返す時 コンテナ内のコマンドラインだけで作業するのは不便が多いです
コンテナのコマンドラインでは実行だけにして ファイル操作は Windows 側の VSCode などで編集したいです

コンテナ内だし samba とかを入れてのフォルダ共有とかだと面倒そうです
WSL なんだし /mnt/c で C ドライブにアクセスできるんだから docker run するときに --mount でマウントしてしまえばできないかなと試してみると あっさり解決できました

sudo docker run -it --mount type=bind,source=/mnt/c/files/tmp,target=/mnt centos:8

コンテナのイメージはとりあえず centos8 にしました
C:\files\tmp をコンテナ内の /mnt で見れます
あとはこのフォルダ内に必要なファイルを作って シンボリックリンクでそれぞれの場所に配置します

この方法だと実体は Windows 上のファイルです
読み書き速度が求められる場合は WSL2 内のフォルダをコンテナにマウントして Windows からは \\wsl$\ でアクセスするほうが良いかもです

気分を変えて debian を使っていて docker を起動しようとしたら起動できませんでした
実行するとデーモンにつながらないというエラーで status では failed になってます

user@SURFACE:~$ docker -v
Docker version 18.09.1, build 4c52b90
user@SURFACE:~$ sudo docker run -it centos:8
[sudo] password for user:
docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?.
See 'docker run --help'.
user@SURFACE:~$ sudo service docker status
[FAIL] Docker is not running ... failed!

start したときは ok って書いてたはずだけど
もう一度 start してみるも status では failed と言われます

user@SURFACE:~$ sudo service docker start
grep: /etc/fstab: No such file or directory
[ ok ] Starting Docker: docker.
user@SURFACE:~$ sudo service docker status
[FAIL] Docker is not running ... failed!

debian だと特別な設定いったりするのかなと調べると同じ問題の issue が
https://github.com/microsoft/WSL/discussions/4872

なんか fstab を作って iptables をレガシーモードにすればいいんだとか
よく見れば service の start 時に fstab がみつからないとメッセージが出てますし
docker のログには iptable がどうこういうメッセージが出てました

やってみると

user@SURFACE:~$ sudo touch /etc/fstab
user@SURFACE:~$ sudo update-alternatives --set iptables /usr/sbin/iptables-legacy
update-alternatives: using /usr/sbin/iptables-legacy to provide /usr/sbin/iptables (iptables) in manual mode
user@SURFACE:~$ sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
update-alternatives: using /usr/sbin/ip6tables-legacy to provide /usr/sbin/ip6tables (ip6tables) in manual mode
user@SURFACE:~$ sudo service docker start
[ ok ] Starting Docker: docker.
user@SURFACE:~$ sudo service docker status
[ ok ] Docker is running.
user@SURFACE:~$ sudo docker run -it centos:8
Unable to find image 'centos:8' locally
8: Pulling from library/centos
7a0437f04f83: Pull complete
Digest: sha256:5528e8b1b1719d34604c87e11dcd1c0a20bedf46e83b5632cdeac91b8c04efc1
Status: Downloaded newer image for centos:8
[root@b200f1bb83d4 /]#

無事 status も ok となりコンテナを起動できました

以前 試したときは特に困りもせずにすんなり使えたのに
別の環境で Docker を使えるようにしようとしたらうまくいきません

docker パッケージは Ubuntu の標準パッケージの docker.io のはず
Fedora ではパッケージ名が途中で docker から docker-ce に変わりましたが
Ubuntu だと docker.io はあるけど docker-ce はないです
リポジトリの追加でつかえるかもですがそういう手間がかかることは前回もしてないはずです

docker.io のインストールはできましたが docker デーモンを起動できません
WSL は systemd が使えないので service コマンドを使うのですが

service docker start

で docker が見つからないと言われます
dockerd や docker.io にしてみてもやっぱりみつからないようです

service --status-all

のリストでもそれらしいものはありません
docker コマンドや systemd 用の service ファイルはあるのですけどね
以前は service コマンドで普通にデーモンが起動できたはずです

実行時のエラーならともかく service 自体がないのだとインストールの問題だと思うので Ubuntu や docker.io パッケージのバージョンの問題でしょうか……

https://news.mynavi.jp/article/20200409-1013112/

良さそう

今でも AppData\Local\Packages 以下の WSL パッケージ内の LocalState\rootfs\ で WSL のルート見れるけど更新すると WSL 側に反映されないのが困るところ
エクスプローラから見れるようにするくらいだからきっとその問題も解決されてるはず