Linux起動時間の高速化：systemdユニット依存関係の分析と最適化

Linuxの起動時間最適化は、特に迅速な起動や一貫したパフォーマンスが不可欠な環境において、システム管理上の重要な側面です。最新のLinuxディストリビューションは、システムおよびサービスマネージャーとしてsystemdに大きく依存しています。systemdは非常に強力ですが、設定ミスや起動の遅いサービスは、全体の起動シーケンスを著しく引き延ばす可能性があります。この記事は、組み込みのsystemdツールを使用して現在の起動パフォーマンスを分析し、ユニットファイル依存関係を管理することで効果的な最適化戦略を実装するための実践的なガイドです。

どのユニットが最も時間を消費し、それらがどのように順序付けられているかを理解することで、逐次的な遅い起動プロセスから、高度に並列化された迅速な起動へと移行できます。ここでは、主にsystemd-analyzeの出力を解釈し、不要なブロッキング依存関係を削除するためにユニットファイルを変更することに焦点を当てます。

systemd起動プロセスの理解

Systemdは、可能な限りサービスを並行して実行することで起動プロセスを管理します。しかし、サービスは、明示的および暗黙的な依存関係がすべて満たされたときにのみ開始できます。ユニットAが進行する前にユニットBが完全にアクティブであることを要求する場合、ユニットAはユニットBによってブロックされます。これらのブロッキング依存関係を特定することが、高速化への第一歩です。

主要なsystemd分析ツール

Systemdは、起動パフォーマンスを診断するためのいくつかの強力なコマンドラインユーティリティを提供します。次のツールは、ボトルネックを特定するために不可欠です。

1. systemd-analyze (全体像)

このコマンドは、カーネル、ユーザースペースの初期化、およびロードされたターゲットにかかった合計時間に関するハイレベルな概要を提供します。

systemd-analyze

出力例の解釈:

コンポーネント	所要時間
Kernel	1.234秒
Initrd	0.500秒
Userspace	5.789秒
Total	7.523秒

これにより、ボトルネックがカーネルフェーズ（ファームウェア/ドライバのロード）にあるのか、ユーザースペースフェーズ（サービス起動）にあるのかを迅速に確認できます。

2. systemd-analyze blame (遅いユニットの特定)

これは、最適化にとっておそらく最も重要なコマンドです。ロードされたすべてのユニットを、初期化（メインプロセスのロードと実行）に費やした時間でソートし、実行時間が長いものが先頭に表示されます。

systemd-analyze blame

焦点: 上位10エントリに注目してください。これらは起動中に積極的に時間を消費しているサービスです。初期化時間が長いことは、サービスが多くの作業を実行していることを単に意味する場合があることに注意してください。目標は、この作業が起動中に必要であるかどうかを確認することです。

3. systemd-analyze critical-chain (依存関係分析)

このコマンドは、起動ターゲット（通常はgraphical.targetまたはmulti-user.target）につながる依存関係チェーンを示します。システムが完全に起動したと見なされる前に完了しなければならないユニットのシーケンスを強調表示します。

systemd-analyze critical-chain

クリティカルチェーンにリストされているユニットは、それらを遅らせるとシステム全体の起動が遅れるため、最適化の主要なターゲットとなります。

4. systemd-analyze plot (起動シーケンスの視覚化)

並列処理とブロッキングの視覚的表現については、プロットコマンドを使用します。これによりSVGファイルが生成されます。

systemd-analyze plot > boot_analysis.svg
# boot_analysis.svgをウェブブラウザで開く

このグラフは、どのサービスが並行して実行され、どのサービスが他のサービスを待っているかを視覚的に示し、依存関係の問題を即座に明確にします。

最適化手法：ユニットファイルの変更

上記のツールを使用して遅いユニットやブロッキングユニットを特定したら、最適化には、ユニット自体の速度を上げるか、いつ実行される必要があるかを変更するかのいずれかが含まれます。

1. blameで特定された遅いユニットへの対処

blameの出力で上位にリストされているサービス（例：slow-database.serviceが10秒かかる）が、基本的なシステム操作（ログインや基本的なネットワーキングなど）にすぐに必要でない場合は、起動を遅らせることを検討してください。

アクション: 起動依存関係のレベルを変更します。

• 現在multi-user.targetをターゲットにしている場合は、ユーザーがログインした後、または明示的に要求されたときにのみ開始されるように移動できるかを確認します。
• サービスがオプションである場合（例：めったに使用されないバックアップツール）、ユニットファイルでDefaultDependencies=noを設定し、必要な最小限の依存関係のみを明示的に定義するか、起動時に必要ないのであれば無効にすること（systemctl disable <unit>）を検討してください。

2. Wants, Requires, Afterを使用した依存関係の最適化

ユニットファイルは、依存関係ディレクティブを使用して実行順序を制御します。ここでの設定ミスは、不要な逐次実行の一般的な原因です。

依存関係の種類：

• Requires=: 強力な依存関係。要求されたユニットが失敗した場合、このユニットも失敗します。
• Wants=: 弱い依存関係。このユニットは要求されたユニットが利用可能であれば開始しますが、要求されたユニットが失敗した場合でも開始を試みます。
• After=: 順序指定ディレクティブ。このユニットは、指定されたユニットの起動が完了した（成功したかどうかにかかわらず）後にのみ開始されます。
• Before=: 順序指定ディレクティブ。このユニットは、指定されたユニットの前に開始される必要があります。

ベストプラクティスのヒント：可能な限りRequiresよりもWantsを優先します。 Wantsを使用すると、オプションのサービスが失敗するのをsystemdが待つ必要がなくなり、他の依存関係を持つサービスも並行して続行できるため、並列処理が向上します。

不要なAfter=制約の削除

起動時間を短縮する最も効果的な方法は、不要な順序制約を排除することです。ユニットAがユニットBの開始前に機能的に依存していない場合、ユニットAの定義からAfter=unit-b.serviceの行を削除します。

修正例（概念的）：

カスタムアプリケーションユニットapp.serviceが、ネットワーク設定サービスを不必要に待機していると仮定します。

# /etc/systemd/system/app.service
[Unit]
Description=My Application
Requires=network.target
After=network.target  <-- おそらく不要な待ち時間！

[Service]
ExecStart=/usr/bin/myapp

アプリケーションがローカルループバックインターフェースまたはローカルファイルロックの確立のみを必要とする場合、完全なネットワークスタック（network.target）を待つことは数秒を無駄にしている可能性があります。アプリケーションが真に外部ネットワークを必要としないことを確認した場合、After=network.targetの行を削除してください。Systemdはその後、ネットワーク設定と並行してapp.serviceをできるだけ早く開始しようとします。

3. 不要なサービスのマスク

systemd-analyze blameが、まったく必要のないサービス（例：サーバー上の不要なBluetoothサポートや特定のハードウェアモニター）が実行されていることを示している場合、それを無効にするかマスクすることで、起動そのものを停止できます。

• 無効化: systemctl disable <unit>（将来の起動時に起動しないようにします）。
• マスク（より強力）: systemctl mask <unit>（ユニットを/dev/nullにリンクし、手動での開始試行も防ぎます）。

# 例：セルラーモデムがない場合のModemManagerのマスク
sudo systemctl mask ModemManager.service

変更の再ロードと検証

いずれかのユニットファイル（特に/etc/systemd/system/に配置されたもの）を変更した後、テストのために再起動する前に、systemdに設定デーモンをリロードするように伝える必要があります。

sudo systemctl daemon-reload

# 次に、再起動する前に依存関係またはステータスを確認します
systemctl list-dependencies myapp.service

最後に、起動シーケンスへの真の影響を測定するために、必ずシステムを再起動してください。

sudo reboot

再起動後、最適化によって達成された時間短縮を定量化するために、直ちにsystemd-analyzeを再度実行してください。

結論

systemdを介したLinux起動時間の最適化は、分析、特定、変更、検証という体系的なプロセスです。systemd-analyze blameとcritical-chainを活用することで、起動のボトルネックに関する正確な洞察を得ることができます。必須ではないAfter=依存関係の削除と不要なサービスの無効化に焦点を当てることで、最も大きなパフォーマンス向上が得られ、システムはログインプロンプトにずっと速く到達できるようになります。