systemdイニットシステムを使用するLinuxディストリビューションに組み込まれたsystemd-analyzeユーティリティは、ユーザーがブートプロセスの遅延原因を迅速に特定できるようにします。簡単なコマンドを実行することで、ブート時間をカーネルとユーザースペースのコンポーネントに分解し、遅延を引き起こすサービスを強調します。このツールは、管理者が推測せずにスタートアップ速度を向上させるための対象的な調整を行うのを支援します。
systemdベースのディストリビューション、例えばUbuntuやFedoraで起動が遅いLinuxユーザーは、組み込みのsystemd-analyzeツールを使って迅速な診断が可能です。技術ガイドで説明されているように、このツールはsystemdが管理する初期化シーケンスを分析し、ファームウェア、ブートローダー、カーネル、ユーザースペースなどのステージの所要時間を報告します。nn基本コマンドsystemd-analyzeを実行すると、総ブート時間の概要が表示されます。例えば、ある例ではカーネルが6.669秒、ユーザースペースが30.368秒で合計37.037秒、グラフィカルターゲットはユーザースペース内で27.479秒後に到達しています。コンパクト版のsystemd-analyze timeは同様の内訳を提供し、SSDシステムではしばしばユーザースペースが主なボトルネックであることを明らかにします。nnblameオプションは初期化時間でsystemdユニットを長い順にリストアップします。一般的な遅延はDebianベースのシステムで日次更新チェックを扱うapt-daily.service（あるケースで57.158秒）、snapd.service（17.609秒）、docker.service（10.647秒）などのサービスからです。ガイドではこのリストを確認して無効化可能なサービスを特定することを勧め、Dockerのようなコンテナランタイムを即座に必要としない場合は遅らせる一方、自動更新などの必須タスクの無効化には注意を促しています。nnより深い洞察のために、systemd-analyze critical-chainはデフォルトターゲットを遅らせる依存パスを追跡します。出力例ではgraphical.targetがmulti-user.targetを待っており、それがdocker.service（16.830秒開始で10.647秒かかる）に依存していることが示されます。これにより、ネットワーク待機サービスや設定ミスのマウントによる30-90秒のタイムアウトなどのボトルネックが明らかになります。nn最後に、systemd-analyze plot > boot.svgでブートプロセスの視覚的なSVGタイムラインを生成し、並列および直列の依存関係を示します。ブラウザでファイルを開くと、サンプルビジュアルのように18秒前後の遅れて開始するユニットが強調されます。nn管理者は、タイマーの再スケジュールやクラウド環境以外でのcloud-initのような不要パッケージの削除などの変更を適用することで、SSDシステムのユーザースペース時間を20-40%短縮するなどの大きな改善を報告しています。これらの変更は元に戻せるよう文書化し、システムの信頼性を確保すべきです。