みなさん、こんにちは。
Windows 11の上でWSL（Windows Subsystem for Linux）を扱う上で、以前はGUIアプリの取り扱いが鬼門でした。Xサーバーを独自にたてて設定するなど、一工夫が必要だったわけです。
しかし、WSL2になり、WSLgの登場によって、LinuxのGUIアプリがまるでWindowsのネイティブアプリのようにシームレスに動くようになり、本当に便利になりました。
しかし、そんな便利なWSLg環境で、最近「ちょっとしたストレス」を感じていました。
「FileZillaやFirefoxを起動しようとすると、1回目は無反応（またはウィンドウが出ない）なのに、もう一度実行すると何事もなかったかのように起動する……」
この、1回目だけ「空振り」する奇妙な現象。実はこれ、WSLg特有のDBus（D-Bus）セッションの初期化タイミングが関係していました。今回は、この問題の原因を深掘りしつつ、一発で安定して起動させるための魔法のコマンド「dbus-launch」の活用法について解説します。
発生している現象 – 1回目が「タスクバー止まり」
まずは、どのような現象が起きているか整理してみます。Ubuntu上のWSLg環境で、例えばFileZillaを起動した際、コンソールには以下のようなメッセージが表示されることがあります。
Gdk-Message: Unable to load sb_h_double_arrow from the cursor theme
Gdk-Message: Unable to load sb_v_double_arrow from the cursor theme
wxD-Bus: Signal: Error: The name org.gnome.SessionManager was not provided by any .service files
この時、Windows側の画面では以下のいずれかの状態になります。
- ウィンドウが全く表示されない。
- タスクバーにアイコンだけが表示されるが、中身（ウィンドウ）が出てこない。
- 一瞬表示されそうになってすぐ消える。
しかし、もう一度同じコマンドを叩くと、今度は嘘のようにスムーズに起動するのです。Firefoxなどのブラウザでも同様の挙動が見られることが多く、「毎回2回起動しなきゃいけないの？」と首を傾けていました。
原因の核心 – DBusとセッションの「すれ違い」
なぜ「1回目」だけ失敗するのでしょうか？その正体は、Linuxのプロセス間通信機構であるDBus（Desktop Bus）にありました。
WSL特有の「軽量・切断型」環境のワナ
WSLは、フルセットのデスクトップLinux（GNOMEやKDEなどが常駐している環境）とは異なり、必要な時だけ起動し、使わなくなるとリソースを解放する「オンデマンド」な設計になっています。
FileZillaやFirefoxといったGUIアプリは、起動時に「org.gnome.SessionManager」などのサービスを探しに行きます。しかし、WSLgにはフルセットのGNOMEセッションマネージャーは存在しません。そのため、以下のような挙動になりやすいのです。
- 1回目の起動時
→ WSLが起動した直後で、アプリが必要とするDBusセッションがまだ十分に整っていない、あるいはサービスへの接続がタイムアウトしてしまう。 - 2回目以降
→ 1回目の「空振り」によって皮肉にもDBusセッションが活性化（または初期化が完了）しており、同じコマンドでも安定して接続できるようになる。
つまり、「アプリを動かすための土台（セッション）」がアプリ本体の起動スピードに追いついていないのが原因だったわけです。
対処法 – dbus-launchで土台を強制的に作る
この問題を解決する方法が、起動コマンドに「dbus-launch」を組み込むことです。これにより、アプリの起動と同時に、そのアプリ専用のDBusセッションを明示的に立ち上げることができます。
修正前のコマンド（失敗しやすい例）
Windowsのスタートメニューなどから実行される標準的なコマンドは、以下のようになっています。
"C:\Program Files\WSL\wslg.exe" -d Ubuntu --cd "~" -- filezilla
この形式だと、GUIアプリがいきなり「裸」の状態で放り出されるため、タイミング問題に弱くなります。
修正後のコマンド（安定化の決定版）
そこで、以下のように書き換えます。
"C:\Program Files\WSL\wslg.exe" -d Ubuntu --cd "~" -- sh -c "dbus-launch --exit-with-session filezilla"
ここがポイント！
sh -c "..."
シェルを介して実行することで、複数のコマンドや引数を正しく解釈させます。dbus-launch
アプリが動き出す前にDBusセッションを確実に立ち上げます。--exit-with-session
アプリを閉じたら、一緒に起動したDBusセッションも終了させるための設定です。これでゴミが残りません。
この変更によってGUIアプリが正常に立ち上がるようになるはずです。（ただし、100%完璧ではなく、失敗するケースも残る）
他のアプリにも適用すべき？適用の判断基準
この対策は、FileZillaだけでなく、Firefox、Evince（PDFビューア）、GIMPなど、多くのLinux GUIアプリで有効です。もしWindowsメニューから起動して「アイコンは出るけど画面が出ない」という症状があれば、迷わず導入をおすすめします。
ただし、以下のケースでは注意が必要です。
- JetBrains系IDE（IntelliJ, PyCharmなど）
これらのIDEは独自のランタイムを持っており、dbus-launchを挟むと逆に挙動が不安定になる場合があります。 - Waylandネイティブで動くアプリ
最新のアプリで、DBusに依存せずWaylandと直接通信するものは、この対策が不要なこともあります。
まずは「1回目に出ない」症状があるアプリに絞って適用するのが安全な運用と言えるでしょう。
「昔は普通に動いていた気がする」のはなぜ？
古くからのWSL2ユーザーなら、「以前はこんな面倒なことしなくても一発で起動していたのに……」と感じるかもしれません。その直感は、おそらく正しいです。
かつてのWSLg初期の頃は、アプリ側のDBus依存度が今ほど高くなかったり、システム側で用意されていた設定がシンプルだったりしました。しかし、Windows 11のアップデートやUbuntuのバージョンアップ（24.04以降など）に伴い、GUIアプリ側のモダン化（＝DBusセッションへの依存度向上）が進みました。
結果として、「昔からあった潜在的なタイミング問題」が、アプリの進化によって顕在化したというのが真相のようです。今や、dbus-launchを挟むのは、WSLgをより「標準的」かつ快適に使うための作法になりつつあると言えます。
WSLgでの安定したGUI体験のために
最後に、WSLgでGUIアプリを快適に使うためのポイントをまとめます。
- 「1回目だけ起動しない」はDBusセッションの遅延が原因。
dbus-launch --exit-with-sessionを起動コマンドに挟むのが特効薬。- Windowsショートカットのリンク先を書き換えるだけでOK。
WSLは非常に強力なツールですが、LinuxとWindowsの「いいとこ取り」をしているがゆえに、こうしたちょっとした摩擦が起きることもあります。しかし、それをコマンド一行で解決していくプロセスもまた、エンジニアとしての楽しみの一つかもしれませんね。
本日も最後までお読みいただきありがとうございました。
それでは、よいWSLライフを！
