kledgeb Ubuntuの使い方や日本語化、アプリの使い方を紹介しています。

デスクトップセッションの開始に使用されているupstartがsystemdに置き換わる

現在デスクトップセッションの開始に「upstart」が使用されていますが、現在この「upstart」を「systemd」に置き換える作業が行われています。


(※)ただし「D-BUS Activation」のほうが都合が良い一部のサービスは、「D-BUS Activation」を使用します。

(※)initの「systemd」化は、すでに「Ubuntu 15.04」で対応済みです。
今回の話は、デスクトップセッションの「systemd」化です。


2週間前我々は、3日かけてUbuntuセッションの多くのサービスを「systemd」で起動するように変更した。
またそれに前後して「systemd」と「upstart」の基盤上で作業を行い、フレーバーで使用されている多くのサービスを「systemd」で起動するように変更し、確認を行った。

現在今回の変更結果を提供する準備が整っており、広くテスト目的で提供できる状態である。

upstartからsystemdへの切り替え

切り替え方法の主軸となる点は、「/usr/share/xsessions/*.desktop」の「Exec=」行に必要な記述を行うことだ。

ディスプレイマネージャーはこれらのファイルを、有効なセッションの表示やセッションの開始方法を知るために利用する。

この仕組みは、「Ubuntu 16.10」で採用される「ubuntu-desktop 3.18.1.2-1ubuntu5」及び「Xbuntu 16.10」で採用される「xubuntu-default-settings 16.10.1」に適用される。

「Kubuntu」や「Lubuntu」など他のデスクトップでは、そもそもデスクトップセッションの開始に「upstart」が利用されていないため、今回のような変換作業は必要ない。

今回の変更に伴い、デスクトップセッションで起動されるソフトウェアの約半分は、「systemd」ユニットにより起動されるようになる。

変更前と変更後で以下のコマンドを実行し、変更内容を確認してほしい。

  • systemctl --user status
  • initctl list|grep run

「Unity」や「HUD」、インジケーターはまだ「upstart」で起動している。
これらの「systemd」への変更は、これから行われる。

systemdへの移行を試すには

今回の変更を試すには、「“Ubuntu Desktop” team」のPPAを追加し、「systemd-graphical-session」パッケージをインストールして欲しい。
そうすれば必要な「systemd」ユニットがインストールされる。

ただし「systemd-graphical-session」パッケージは、今回の変更が採用されればPPAから削除され、PPAの中身は空になる。

補足

「dbus」や「gnome-session」などいくつかの「upstart」ジョブは、まだ「upstart」で起動する。
しかしこれらのプログラムは、スタブジョブになるように「sleep infinity」で起動するよう変更している。
「systemd」への移行作業が終了するまで、これらのプログラムが依存により必要になるためである。

つまり最終的に「upstart」ジョブに依存している部分は、すべて「systemd」のみで動作するように変更される。

次の段階

次の作業は、まだ作業を行っていないジョブの「systemd」ユニットを提供することだ。
デスクトップにおいて大部分の作業は完了しているが、残りのジョブのうち主だった移行作業はUnity Greeterセッションの移行作業である。 (ログイン画面)

Unity Greeterセッションは「upstart」に依存している。

残りの大部分の作業は、「Ubuntu Touch」向けのパッケージの変更と「ubuntu-app-launch」の変更である。
「systemd」に足りない機能に関しては、いくつか回避策がある。

残りの作業に関しては、「Replace session upstart in the desktop session」で追跡できる。
また不具合の追跡に関しては、「Ubuntu」の「systemd-session」タグが付いている項目で追跡できる。

インジケーターが表示されなくなる

上記のPPAを適用した環境なら、「upstart」を削除し「upstart」なしでデスクトップ環境を利用することができる。
しかし「lightdm」のUnity Greeterセッションでは、インジケーターが表示されなくなる。

でもUnity Greeterセッションでインジケーターがなくてもログインできるし、これらのインジケーターは必須ではない。

D-Busユーザーセッション

「upstart」から「systemd」への移行は、セッション中心のD-Busデーモン及びサービスから、ユーザー中心のD-Busデーモン及びサービスへの移行も必要とする。

「pulseaudio」、「gvfs」、「SSH」、「agents」、「keyring daemon」といったD-Busサービスは、同じユーザーがSSHやVTといったCUIから複数ログインしてもそのまま活用できる。
そのためログインしている同じユーザーが全てログアウトするまで、これらのサービスは終了しないようになる。
この点については、以下を参照して欲しい。


この変更は、「dbus-user-session」パッケージのインストールにより適用される。
そして「ubuntu-session」及び「xubuntu-default-settings」パッケージは、「dbus-user-session」パッケージに依存するようになる。
またこの変更により、「policykit」、「gnome-keyring」、「AppArmor」プロファイルが影響を受けるが、「Ubuntu 16.10」で必要な修正がすべて行われる。

現時点でこれといった問題は見当たらないが、何か問題を見つけたら「systemd-session」タグを付けて不具合を報告して欲しい。

デスクトップセッションで使用されているupstartを他の仕組みに置き換えるには

以前UDSで行われた本件に関する議論の内容です。


「Ubuntu 15.04」にてシステムの「init」は、「upstart」から「systemd」へと移行した。
しかし「upstart」は今でもセッションの開始や起動のために利用されており、「upstart」パッケージは引き続きメンテナンスが行われ提供されている。

「upstart」パッケージの提供をやめるために、次のLTSである「Ubuntu 18.04」ではこの依存を解消する必要がある。

そのため、以下の点について議論及び調査する必要がある。

  1. 現在「upstart」が何に利用されているのか
  2. 「gnome-session」及び「D-Bus」によるソフトウェアの起動から脱却し、「upstart」へ移行した本来の理由は何だったのか
  3. 「upstart」ジョブを他の仕組みに移行できるかどうか

他の仕組みとは、以下の仕組みが挙げられる。

  • gnome-session+xdg-autostart
  • D-BUS Activation
  • user systemd

補足

ユーザーがログインすると「upstart」が起動し、デスクトップを構築するために必要なソフトウェアが「upstart」により起動されます。


セッションは、ユーザーがログインするとそのユーザーのセッションが作成され、ユーザーがログアウトするとそのユーザーのセッションが削除されます。
(ログインセッション/ユーザーセッション)
このセッションはGUIでもCUIでも同じように生成及び破棄されます。

セッションは、ユーザーのプロセスや環境を管理する仕組みだと思えば良いです。

ユーザーが「Dash」等アプリケーションランチャーからアプリを起動すると、「upstart」の子プロセスとしてアプリが起動します。

「upstart」の提供をやめるためには、現在「upstart」でログイン時に起動しているソフトウェアを、他の仕組みで起動するように変更する必要があります。
その仕組みをどうしようか、という話です。

デスクトップセッション

上記ではデスクトップ(GUI)向けのセッションを、デスクトップセッションと表現しています。

つまり「Ubuntu Desktop」でユーザーがログインした時に生成されるセッションが、デスクトップセッションになります。
GUIなのでグラフィカルセッションとも表現されます。

upstartを採用した理由

「upstart」を採用した理由には、以下の理由が挙げられる。

1.サービスの自動的な再起動

サービス(デーモン)がクラッシュした時に自動的にサービスを再起動できる。
また、再起動の制限も指定できる。

2.dbus-daemonには必要な機能が欠けていた

「dbus-daemon」から脱却した理由は、サービス管理機能において我々が必要とする機能が欠けていたためである。
例えばインジケーターは、インジケーター自身によって起動させる必要がある。

3.サービスの起動条件の指定

「upstart」は、サービスの起動条件の指定方法が要件に合い十分である。
例えば「xdg-autostart」では、サービスの起動に指定できる条件が少なく不十分である。

4.ログの作成

プロセスごとにログを分けて出力できる。

仕組みに要求される機能や要件

他の仕組みに移行するとして、その仕組みに必要とされる機能は、上記の「upstartを採用した理由」であげた内容を満足させる仕組みでなければならない。
また仕組みの移行にあたり、いくつかの要件を満たす必要がある。

1.dbus-activation+gnome-session

「dbus-activation」と「gnome-session」では、上記の理由を満足させる条件を満たさない。
従って「upstart」の提供を辞めるなら、「user systemd」(systemd --user)を利用する必要がある。

2.段階的な移行

急に仕組みを移行するのではなく、段階的に仕組みを移行したい。
現在「upstart」で起動しているソフトウェアを「systemd」で起動するように置き換えていく。

3.ユーザーごとにデスクトップセッションを1つだけ作る

ディスプレイマネージャーである「lightdm」や「gdm」は、1人のユーザーに1つのデスクトップセッションしかサポートしていない。
従ってユーザーごとに存在するセッションは、1つでなければならない。

補足

例えばログイン画面から「userA」でログインした後、ユーザーの切り替えを行い、新たに「userA」でログインすることはできません。

「userA」でログイン後にユーザーの切り替えを行い、ログイン画面から「userA」でログインしようとすると、すでにログイン済みの「userA」の画面に戻ります。
従って「userA」のセッションを2つ以上生成することができません。

言い換えれば、ユーザーの切り替えにより「userA」の画面がロックされ、ユーザーのパスワードの入力により、ロックから復帰した状態です。

ログイン画面に戻るには、ユーザーがログアウトするか、ユーザーを切り替える必要があります。
ユーザーがログアウトすれば、そのユーザーのセッションが破棄されるため、そのユーザーでログインすればそのユーザーのセッションが新規に生成されます。

4.柔軟性

「gnupg-agent」などが他の仕組みへ移行しても、「dbus-activation」へ戻すことができる。

user systemd(systemd --user)の利用

「user systemd」は、特定のセッションに縛られることなく、すべてのセッションを横断してサービスを起動できるよう設計されている。

例えば「gvfs」や「pulseaudio」はすでに「user systemd」を利用しており、各セッションごとに1つずつインスタンスを持つ必要がない。

しかしセッションを横断してサービスを起動する方法を「X.Org」や「Mir」のログインセッションで利用すると、GUIアプリが動作しなくなる。

この問題に対処するため、グラフィカルセッション用の包括的なsystemdユニットを用意し、サービスの起動と停止にのみ利用する。


関連記事一覧
オプション