Systemd と D-Bus 統合

正しくインストールされていれば¹、Ghostty にはいくつかの systemd ユニットが付属します。これらの systemd ユニットを介して Ghostty を実行するのが推奨される方法です。Ghostty の systemd 統合が提供する最も重要な利点 2 つは：即時起動²と集中ログ記録です。

systemd を備えたシステムで、システムパッケージまたは ドキュメントの通り で Ghostty をインストールした場合、Ghostty は そのまま動く はずです。仕組みを理解したい、またはトラブルシュートしたいのでない限り、このドキュメントを読む必要はありません。

Important

Ghostty は systemd を 必要としません。systemd なしのシステムでも ghostty バイナリを直接実行でき、Ghostty は依然動作します。ただし、このページで文書化された利点は失われます。

Important

設定ファイルで class を使用すると、systemd ユニットファイルや D-Bus 活性化の正常な動作を妨げる可能性があります。設定ファイルから除去し、必要時にのみコマンドラインで明示的に使うことをお勧めします。

Ghostty をログイン時にバックグラウンドで起動するよう設定できるので、以後の新ウィンドウ作成要求は非常に速くなります。これは systemd で Ghostty のユーザーサービスを有効化して行います：

systemctl enable --user app-com.mitchellh.ghostty.service

こうすることで、ログイン時に Ghostty を起動するようシステムが構成されますが、ウィンドウは作成されません。起動時の遅れは、ログイン後にシステムが残りのセットアップを仕上げる時間によって「隠蔽」されます。

設定にいくつかの設定項目を加えると、体験をさらに改善できます：

quit-after-last-window-closed = true
quit-after-last-window-closed-delay = 5m

この設定では、最後のウィンドウが閉じてから 5 分後に Ghostty が終了し、Ghostty をしばらく使っていない場合のメモリを節約します。

quit-after-last-window-closed = false

この設定では Ghostty を常に実行し続けるので、新しいウィンドウの作成はいつも速くなります。

Ghostty に設定を再読み込みさせるには（スクリプトや CLI から）、このコマンドを使います：

systemctl reload --user app-com.mitchellh.ghostty.service

舞台裏ではメインの Ghostty プロセスに SIGUSR2 を送るだけですが、メインの Ghostty プロセスの追跡は systemd が担当します。ps などの類似ユーティリティでこれをスクリプト化すると、信頼性が低くなることがあります。

引数なしの ghostty CLI で新しいウィンドウを作成できます。しかし、systemd と D-Bus 統合を使用しているなら、代わりに ghostty +new-window を使うほうがずっと速いです。

+new-window コマンドは D-Bus を直接使って新しいウィンドウを作成します。Ghostty が実行中でなければ、D-Bus 活性化ユニットが Ghostty を起動します。これは素の ghostty よりはるかに速いです。なぜなら、素の実行では設定の読み込み、環境の検査、GTK の初期化などを経て同じ結論に到達しなければならないからです。

ghostty +new-window

Ghostty がまだ動いていなくてもこのコマンドは新しいウィンドウを作成します。D-Bus 活性化により Ghostty が起動されるからです。

このコマンドは特に i3、Hyprland、River のようなウィンドウマネージャーにとって便利です。

以下は Hyprland で super+return を新しい Ghostty ウィンドウを開くようにバインドする例です。この設定は通常 ~/.config/hypr/hyprland.conf に置きます：

bind = SUPER, return, exec, ghostty +new-window

systemd と D-Bus を備えたシステムでは、Ghostty はデフォルトで D-Bus 活性化により起動します。

アプリケーション起動機構は Ghostty を直接実行するのではなく、D-Bus セッションブローカーにシグナルを送り、Ghostty のウィンドウを開くよう依頼します。D-Bus セッションブローカーは Ghostty が動作中か否かを知っています。Ghostty は特定のバス名（com.mitchellh.ghostty）を登録するためです。このバス名を登録したプログラムがあれば、それが Ghostty とみなされます。

この時点から、挙動は Ghostty が動作中か否かにより分かれます。

このプロセスは、GTK（または他の初期化）がもたらす起動遅延が、実行中のウィンドウがある場合または Ghostty が常駐するよう設定されている（デフォルトはそうではない）場合にのみ、一度だけ負担されるよう保証します。

Ghostty が動作中の場合は、ブローカーは Ghostty に直接 D-Bus シグナルを送り、新しいウィンドウの作成を依頼します。Ghostty はこのシグナルを待ち受け、新しいウィンドウを開きます。これは非常に速く、非常に軽いです。

Ghostty が動作していない場合は、D-Bus セッションブローカーが systemd に対してユーザーサービスで Ghostty を起動するよう依頼し、Ghostty の起動後に D-Bus シグナルを送って新しいウィンドウの作成を依頼します。

この「その他」セクションは、より重大でない情報またはあまり使われない情報を集めます。この情報は依然として重大に有用（そこでここに文書化）ですが、頻繁に使用されません。

systemd を介して実行された Ghostty が出力するログは journalctl で見られます：

journalctl -a -f --user -u app-com.mitchellh.ghostty.service

次のコマンドは Ghostty の状態を表示します：

systemctl status --user app-com.mitchellh.ghostty.service

出力はこのようなものになるはずです：

● app-com.mitchellh.ghostty.service - Ghostty
     Loaded: loaded (/home/mitchellh/.local/share/systemd/user/app-com.mitchellh.ghostty.service; disabled; preset: enabled)
     Active: active (running) since Fri 2025-07-11 14:05:42 PDT; 24h ago
 Invocation: 42b48b0aa1bf4134a030e38acb04b8dd
   Main PID: 2525 (ghostty)
      Tasks: 0 (limit: 71639)
     Memory: 81.4M (peak: 107.9M)
        CPU: 98ms
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/app-com.mitchellh.ghostty.service
             ‣ 2525 /home/mitchellh/.local/bin/ghostty --launched-from=systemd

Jul 11 14:05:42 beach ghostty[2525]: info(gtk): cgroup isolation enabled base=/user.slice/user-1000.slice/user@1000.service/app.slice/app-ghostty-transient-2525.scope
Jul 11 14:05:42 beach systemd[2268]: Started Ghostty.
Jul 11 14:05:42 beach ghostty[2525]: info(gtk): received new window action
Jul 11 14:05:42 beach ghostty[2525]: info(opengl): loaded OpenGL 4.6
Jul 11 14:05:42 beach ghostty[2525]: info(io_exec): found Ghostty resources dir: /home/mitchellh/.local/share/ghostty

Ghostty の systemd ユーザーサービスは実行により停止できます：

systemctl stop --user app-com.mitchellh.ghostty.service

Caution

これは Ghostty を安全に停止させますが、Ghostty はすべてのウィンドウを閉じ、その中で動作しているプロセスを 確認を求めずに 強制終了します。これはデータまたは状態の損失を起こす可能性があります。

正しくインストールされている場合¹、Ghostty は Ghostty を起動するためのいくつかの設定ファイルを付属します。

ユーザーとしてインストールされた場合（例えば $HOME/.local）は以下のファイルが作成されます：

$PREFIX/share/applications/com.mitchellh.ghostty.desktop
$PREFIX/share/dbus-1/services/com.mitchellh.ghostty.service
$PREFIX/share/systemd/user/app-com.mitchellh.ghostty.service

システムパッケージとしてインストールされた場合は以下のファイルが作成されます：

$PREFIX/share/applications/com.mitchellh.ghostty.desktop
$PREFIX/share/dbus-1/services/com.mitchellh.ghostty.service
$PREFIX/lib/systemd/user/app-com.mitchellh.ghostty.service

Warning

これらのファイルが正しい場所にインストールされず、設定が正しくない場合、Ghostty の起動に失敗する可能性があります。ファイルが正しい場所にありながら Ghostty が起動しない場合は、ログアウトして再度ログインしてください。それでもうまく行かないときは、システムの再起動を試みてください。これは必要となることは珍しいですが、システム構成によっては起こり得ます。

Ghostty の開発ビルドをインストールした場合（Debug モード）、このページのパスを少し変更する必要があります：

systemctl enable --user app-com.mitchellh.ghostty-debug.service
systemctl stop --user app-com.mitchellh.ghostty-debug.service
systemctl reload --user app-com.mitchellh.ghostty-debug.service
journalctl -a -f --user -u app-com.mitchellh.ghostty-debug.service
ghostty +new-window --class=com.mitchellh.ghostty-debug.service

これらはユーザーとしてインストールされた場合の Ghostty デバッグ版の起動を制御するファイルです：

$PREFIX/share/applications/com.mitchellh.ghostty-debug.desktop
$PREFIX/share/dbus-1/services/com.mitchellh.ghostty-debug.service
$PREFIX/share/systemd/user/app-com.mitchellh.ghostty-debug.service

システムパッケージとしてインストールされた場合は以下の位置にファイルがあります：

$PREFIX/share/applications/com.mitchellh.ghostty-debug.desktop
$PREFIX/share/dbus-1/services/com.mitchellh.ghostty-debug.service
$PREFIX/lib/systemd/user/app-com.mitchellh.ghostty-debug.service

Footnotes

1. 「正しくインストール」とは、私たちのパッケージングガイドラインに従ったパッケージによるもの、または $HOME/.local でソースからのものを指します。 ↩ ↩²

2. 「即時」はもちろん誇張です。実際上は、新しい Ghostty ウィンドウの起動が現代のシステムの約 300ms から約 20ms に下がります。具体的な数字はハードウェアにより異なりますが、相対的な改善はすべてのシステムで顕著なはずです。 ↩