WSLは基本的には開発者向けにCUI環境を提供しており、
X Serverを動作させることで簡易的なGUIアプリも立ち上げ可能ではありますが、
WSL2の環境で gnomeのデスクトップ環境をフルで立ち上げるのは結構難しいです。
試行錯誤の結果、意外とすんなり動作することが分かったので
備忘録として設定手順を残しておきます。
WSL2は非常に便利で、もはや離れられない程お世話になっておりますが、
大きな問題点の１つとして systemedが利用できない点が挙げられます。
Linuxシステムでは起動直後に全てのプロセスのfork元となる pid 1 のinitが立ち上がります。
Redhat系を中心とするモダンなディストリビューションではinitプログラムとして
systemedが pid 1で起動し、各種デーモンやシェルを起動してシステムを利用可能な状態にしてくれます。
一方、WSL2の環境では initとして Microsoftが用意した最低限の機能を持つ
カスタム init が起動するようになっており、 systemedは無効になっています。
このため systemedに依存したデーモンやその管理ツールが動作しません。
systemctl などが使えなずサーバの立ち上げ方に困ることはよくあると思います。
gnomeもsystemedに依存しているため、単に gnomeのデスクトップ環境を導入しても
起動に失敗してしまいます。
環境
- Windows 10 Pro ver 20H2
- WSL2
- fedora remix @ Store ( fedora 33 までupgrade 済み)
- X410 (X server)
動作確認
設定概要
設定の流れ
- 環境変数の設定
- group installにて gnome-desktop をインストール
- demonize / unshare / nsenter のインストール
- genieの導入
- dotnet5の sdk/runtimeのインストール
- git clone / make local
- 手動配置
genieによるsystemed (pid 1)の動作について
冒頭にも書いた通り、gnomeや一部のサーバソフトウェアの動作には
pid = 1 で動作する systemedがあるととても助かることが多いのですが…
WSL2用の MS製initを止めるわけにもいかないから困っているわけです。
その為以下のようなテクニックを使う必要があります。
こちらの記事が簡潔です。
unshareはコンテナ技術で利用される kernel namespaceを操作するコマンドです。
Kernelの管理しているリソースの namespaceを分離することで parentと独立したnamespaceが
利用可能できます。pid namespaceを切り離せば同じホストで同一の pidの並存が実現できます。
この手法を使ってシンプルなコンテナの中で pid =1 でsystemedを動作させることを目指します。
ただしこれらのコマンドを毎回操作するのは面倒なのでラッパープログラムのgenieを利用することになります。
genieは debian / ubuntu での動作を前提に作られており、これらのディストリビューションでは
パッケージシステムで導入できます。
fedora / cent os 等 Redhat系のOSでは自分でビルドする必要があります。
コメントする