「Windows Subsystem for Linux」が「systemd」に対応へ – 窓の杜 (impress.co.jp)
WSLのsystemd対応の話は大分前から知っていたが、WSLアップデート直後からDNSが原因でupdateや再インストールができなくなったため、Hyper-Vに逃げていた。
サービスを動かす環境は安定しないと話にならない。後、WSLのインストールに失敗していたのもある。
Ubuntuをアプリ設定からアンインストールし、PowerShellからディストリビューションのインストールをしたら今度はいけた。
少し余裕ができたので再チャレンジ。
実行環境
| CPU | Intel Core i9-13900 |
| メモリ | DDR4-3200 128GB |
| VGA | NVIDIA GeForce RTX3050 |
| OS | Windows 11 Pro 64bit |
| WSL | 1.2.5.0 |
| カーネル | 5.15.90.1 |
結果
- シェルやVS CodeなどでWSL起動しておかないとWSLのプロセスが終了する。
- rebootコマンドは使える。
1について。
要するに、タスクスケジューラで起動するなど常駐してあげないとダメなのは変わりなし。
折角、systemd対応したのに、Windowsとの統合が不十分。今後に期待。
VS Codeのターミナルで使っている分には気にしなくてよい。
PuTTYなどSSH経由なら注意。
通信中にWSLを落とすような操作をした途端に切断される。
後、使いやすくなったが、やはり、WindowsやWSLのアップデートで環境をぶっ壊される可能性があるので注意。
安定した環境を望むならHyper-Vの方が断然良い。
Hyper-Vも一時期.NET関連でHyper-Vマネージャーが起動しなくなったが…。
WSLはWindowsのプロセスとして動く強みがあって、Windowsが認識しているデバイスはWSL環境上でも認識する。
CUDAのインストールは問題なく通った。
dmesg
軽くチェック。
[ 0.000000] Linux version 5.15.90.1-microsoft-standard-WSL2 (oe-user@oe-host) (x86_64-msft-linux-gcc (GCC) 9.3.0, GNU ld (GNU Binutils) 2.34.0.20200220) #1 SMP Fri Jan 27 02:56:13 UTC 2023
[ 0.000000] Command line: initrd=\initrd.img WSL_ROOT_INIT=1 panic=-1 nr_cpus=32 bonding.max_bonds=0 dummy.numdummies=0 fb_tunnels=none swiotlb=force console=hvc0 debug pty.legacy_count=0
…（中略）…
[ 0.121245] ACPI: bus type PCI registered
[ 0.121245] PCI: Fatal: No config space access function found
[ 0.121245] Kprobes globally optimized
…（中略）…
[ 0.139831] Freeing initrd memory: 1936K
[ 0.302098] kvm: already loaded the other module
[ 0.304360] Initialise system trusted keyrings
…（中略）…
[ 0.785701] memmap_init_zone_device initialised 2097152 pages in 10ms
[ 0.790855] FS-Cache: Duplicate cookie detected
[ 0.791049] FS-Cache: O-cookie c=00000004 [p=00000002 fl=222 nc=0 na=1]
[ 0.791238] FS-Cache: O-cookie d=000000007e1e9fb0{9P.session} n=00000000d616a14d
…（中略）…
[ 3.591985] systemd-journald[40]: File /var/log/journal/057a409405214c629e69f35b1ccb7681/system.journal corrupted or uncleanly shut down, renaming and replacing.
[ 4.539859] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -2
[ 4.678832] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -2
- PCI
→使ってないのでどうでもいい。次。 - kvm
→仮想化モジュールの衝突だがWSLなのでOK。 - FS-Cache
→既知の問題だが影響ないらしい。パフォーマンスの話はどうだろう？
FS-Cache: Duplicate cookie detected · Issue #5694 · microsoft/WSL (github.com) - misc dxg
→色々語られているけど、まだ未解決らしい？これはCUDA関連を使うときに影響が出る可能性。
WSLg/Cuda suddenly broken due to nvidia-smi unable to find GPU · Issue #9099 · microsoft/WSL (github.com)
top
MiB Mem : 64157.8 total, 62861.4 free, 798.6 used, 497.8 buff/cache MiB Swap: 16384.0 total, 16384.0 free, 0.0 used. 62765.9 avail Mem
今更ながら、WSLが認識するメモリは最大64GB？と思ったら、ホスト搭載メモリの容量によるらしい。
WSL での詳細設定の構成 | Microsoft Learn
Windows の合計メモリの 50% または 8 GB のどちらか少ない方。20175 より前のビルドでは、Windows の合計メモリの 80%
と書いてあるものの。
ホスト搭載メモリの50%が既定値のような。
PC#2（Win10 Pro 64bit、メモリ256GB）では128GB、
PC#3（Win10 Pro 64bit、メモリ64GB）では32GBとなっていた。
最もWSL環境で64GBも使うくらいのプログラム起動することはあまりないと思うが…必要なら.wslconfigを編集。
普段はHyper-VのVMにサービス起動して、WSLとHyper-Vで通信するのが現実的。
2023年5月時点では…
WSLの仕様が変わっているらしく、仮想スイッチがPowerShellのGet-NetAdapterで列挙されないし、GUIのアダプター一覧にも出てこない。
ipconfigでは出てくるが、WSLとHyper-Vの通信方法は別に調べないと駄目。
後、ある時点からWSLのaptコマンドでDNS参照エラーを起こすようになっていたが、犯人は自分が使っているESETというセキュリティソフトのファイアウォール。Windows Defenderでは起こらない。
検出率もESETよりDefenderの方が上という結果が出ている。
（値上げするし使うのやめるかこれ…。）
