systemd-analyzeで特定するブート遅延ユニット｜本番サーバの起動時間短縮と依存関係の整理手順

ブート遅延が問題になる運用シナリオ

本番サーバの再起動は、カーネルアップデート適用・ハードウェア障害後の復旧・クラウドインスタンスのスポット中断など、頻度は低くても確実に発生するイベントです。このとき「起動に3分かかる」と「起動に30秒で完了する」では、サービス影響時間に大きな差が生まれます。

現場で多いのは、かつて手動で有効化したサービスが検証目的のまま残り続けているケースです。デプロイを重ねるうちにユニットが蓄積し、依存関係が複雑化して、実際に何が起動を遅らせているのか把握できなくなります。systemd-analyzeはそうした状況を可視化するための標準ツールであり、追加インストールなしで利用できます。

systemd-analyzeが示す情報の構造を理解する

systemdのブートシーケンスは、内部的に3つのフェーズに分かれています。ファームウェア処理（BIOS/UEFI）、ブートローダー（GRUBなど）、そしてカーネルがinitプロセスとしてsystemdを起動してからユーザースペースが完成するまでのフェーズです。systemd-analyzeが計測・表示するのは主にこの3番目のフェーズです。

引数なしで実行すると、カーネル起動からデフォルトターゲット（通常はmulti-user.targetまたはgraphical.target）の到達までに要した合計時間が1行で出力されます。この数値だけでは原因の特定はできませんが、チューニング前後の比較基準として必ず記録しておく必要があります。

$ systemd-analyze
Startup finished in 1.523s (kernel) + 12.341s (initrd) + 47.892s (userspace) = 1min 1.756s
multi-user.target reached after 47.651s in userspace.

userspace フェーズが47秒超と突出している場合、何らかのユニットが並列化の恩恵を受けられずにシリアルに待機しているか、タイムアウトまで待ち続けているサービスが存在している可能性が高いです。

blameとcritical-chainで遅延ユニットを特定する

起動時間の長いユニットを多い順に列挙するにはblameサブコマンドを使います。

$ systemd-analyze blame
  35.201s NetworkManager-wait-online.service
   8.432s cloud-init.service
   3.119s snapd.service
   2.887s accounts-daemon.service
   1.234s apt-daily.service
   ...

blameの出力で注目すべき点は、単純に時間が長いユニットが必ずしも問題の「原因」ではないという点です。あるユニットが他ユニットの完了を待って初めて起動できる構造になっている場合、そのユニット自体は適切に動作していても見かけ上の遅延が積み重なります。原因の連鎖を辿るにはcritical-chainサブコマンドが有効です。

$ systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

multi-user.target @47.651s
└─NetworkManager-wait-online.service @12.089s +35.201s
  └─NetworkManager.service @11.821s +0.266s
    └─dbus.service @11.654s +0.165s
      └─basic.target @11.649s
        └─...

この例では、NetworkManager-wait-online.serviceがクリティカルパスの頂点に位置しています。このユニットは「ネットワークインターフェースがオンラインになるまで待機する」役割を持ちますが、サーバ環境でアプリケーション自身がネットワーク到達性を再試行できる実装になっている場合は、このユニットへの依存を切ることで大幅な短縮が見込めます。

特定ユニットを起点にした依存ツリーを確認するには、以下のコマンドで深掘りできます。

$ systemctl list-dependencies NetworkManager-wait-online.service --reverse

このコマンドにより、問題ユニットに依存している上位ユニットが一覧化され、影響範囲を把握したうえで無効化の可否を判断できます。

依存関係の整理と無効化の実施手順

遅延原因が特定できたら、無効化または設定変更を慎重に進めます。よく見られる対応パターンをいくつか示します。

NetworkManager-wait-online.service の無効化
サーバ環境でNMWOが不要な場合、サービスを無効化します。ただし完全停止ではなく「起動シーケンスから外す」に留めるのが基本です。

$ sudo systemctl disable NetworkManager-wait-online.service

snapdの遅延起動への切り替え
snapdを使用しているがブート即時起動が不要な場合、systemctl maskではなくドロップインファイルでAfter=を調整するか、snapd不要であれば削除の検討も含まれます。本番環境でsnapが管理対象に含まれていないケースでは、アンインストールが根本解決になることもあります。

cloud-init の制御
クラウドインスタンスをゴールデンイメージ化して使い回す運用では、初回セットアップ後にcloud-initを無効化することで起動時間を短縮できます。cloud-init clean --logsでリセット後、touch /etc/cloud/cloud-init.disabledで恒久無効化するのが一般的な手順です。

apt-daily.service / apt-daily-upgrade.service
これらは定期実行ジョブであり、起動直後に動作するとI/Oを占有します。systemdのタイマーユニットで実行時刻をオフピークにずらすか、ランダム遅延（RandomizedDelaySec）を大きく取ることで起動時の競合を回避できます。

変更後の検証と切り戻し手順

変更を施したら、必ず再起動を挟んで効果を確認します。チューニング前後の数値を比較するため、変更前にsystemd-analyzeの結果をファイルに保存しておくことを推奨します。

# 変更前の記録
$ systemd-analyze blame > /tmp/boot_before.txt
$ systemd-analyze critical-chain >> /tmp/boot_before.txt

# 再起動後に再計測
$ systemd-analyze
$ systemd-analyze blame | head -20

切り戻しが必要になった場合の手順も明確にしておく必要があります。systemctl disableで無効化したユニットはsystemctl enableで再有効化できます。systemctl maskを使った場合はunmaskが必要です。maskはdisableより強い操作で、手動起動も含めて完全に封じるため、慎重に使い分けます。

本番環境への適用前に、ステージング環境または同一構成のテストサーバで同じ手順を実施し、依存していたサービスに想定外の影響が出ていないかを確認するプロセスは省略すべきではありません。特にWants=やRequires=で連鎖する依存を持つサービスを変更する際は、journalctl -b -p errで直前のブートのエラーログを確認することで問題を早期に発見できます。

2026年の現行環境における差分と注意点

Ubuntu 24.04 LTS・RHEL 9系・Debian 12以降の環境では、systemdのバージョンが253〜256台に達しており、いくつかの挙動が変化しています。

まず、systemd-analyze plotコマンドが生成するSVGの形式が従来より詳細になり、各ユニットのアクティベーションタイプ（Type=oneshot, forking, notify等）が視覚的に区別されるようになっています。ブラウザで開いて全体像を把握する用途に使いやすくなりました。

次に、systemd-analyze securityサブコマンドの出力が拡充されており、ユニットのサンドボックス設定をスコアリングして表示します。起動時間短縮の文脈ではあまり登場しませんが、無効化候補を検討する際に権限・機能の把握として活用できます。

また、NetworkManager の代わりに systemd-networkd を採用する構成がサーバ向けに広まっています。この場合、NetworkManager-wait-online.serviceではなくsystemd-networkd-wait-online.serviceがクリティカルパスに現れます。どちらが有効かはsystemctl status NetworkManagerとsystemctl status systemd-networkdで確認します。wait-onlineの無効化ロジック自体は同様ですが、対象ユニット名を誤ると意図しないサービス停止に繋がるため注意が必要です。

cloud-init については、バージョン24.x系でモジュールの並列実行対応が強化されており、以前より起動時間の影響が小さくなっているケースもあります。ただしblame出力で上位に表示される場合は従来どおり無効化の検討対象になります。

コンテナ環境（systemdをPID 1として動かすLXC・Podman systemdコンテナ）では、ホストのブートシーケンスとコンテナ内のシーケンスが分離されています。systemd-analyzeをコンテナ内で実行した場合はコンテナ内の起動時間が表示されるため、ホスト全体の計測と混同しないよう注意します。

ブート遅延の特定から無効化・検証・切り戻しまでの一連の作業は、変更ログをチームで共有しながら進めることで、後から別の担当者が理由を追跡できる状態を保つことが長期的な運用品質の維持につながります。