Linux 講座 / systemd サービスと起動ログの確認

Linux

systemdを使用するLinuxでは、起動はファームウェアとブートローダーを経てカーネルが開始された後、システムマネージャーであるsystemdがサービスや他のユニットを起動・管理する流れです。サービスの問題を確認する場合は、systemctlで現在の状態と起動時の有効化設定をそれぞれ確認し、journalctlで同じ起動のログを読みましょう。この二つの状態は互いに異なります。

この記事はsystemdのサービス状態・起動・自動起動設定を確認する入門です。複数の証拠を集めて原因を絞り込む手順はログベース障害分析で扱います。

システム設定実習の基準は Ubuntu 26.04 LTS と Rocky Linux 9 系の一般インストール VM です。コンテナ・WSL・別のリリースでは、サービスやパッケージの構成が異なる場合があります。仮想マシン実習環境の作成で、コンソールの復旧とバージョン確認を最初に準備してください。

起動の流れを大きな段階で理解する

一般的なPC・サーバーの起動は、ファームウェアがハードウェアを初期化し、ブートローダーを探すことから始まります。ブートローダーはカーネルと必要な初期環境をロードし、カーネルはデバイス・メモリ・プロセス実行基盤を準備します。その後、最初のユーザ空間プロセスである初期化システムがサービスなどを管理します。ここではsystemdがPID 1であるディストリビューションを対象としています。他の初期化システムを使用する環境では、コマンドや手順が異なる場合があります。

ps -p 1 -o pid,comm,args
systemctl get-default

最初のコマンドで COMMAND または ARGS が PID 1 で systemd かどうか確認してください。コンテナや特殊な環境では異なる場合があります。二番目のコマンドはデフォルトターゲットを表示します。例えば multi-user.target は一般的なマルチユーザーテキスト環境のターゲットであり、graphical.target はグラフィック環境のターゲットである可能性があります。ターゲットは複数のユニットをまとめる目標であり、すべてのサービスが一行で順番に開始されるという意味ではありません。

systemd ユニットと依存関係

systemd は管理対象を ユニット(unit) として表現します。.service はサービス、.target は複数のユニットをまとめるターゲット、.socket はソケットベースの起動、.timer は時間ベースの実行に関連します。サービスを利用するには、該当プログラムパッケージとユニットが実際にインストールされている必要があります。名前を推測して運用サーバーのサービスを開始または停止しないでください。

サービス開始順序は単純な数字の順序ではなく、ユニット間の依存関係と順序ルールに従って決定されます。あるユニットが他のユニットの後に開始されるように設定されていても、その順序設定だけで、他のユニットも起動対象として要求されるわけではありません。起動中の一部のユニットは並行して実行されるため、遅い起動の原因をリストの上下だけで特定することはできません。

systemctl list-units --type=service --state=running
systemctl --failed

最初のコマンドは現在ロードされて実行中のサービスユニットを、2番目は失敗状態のユニットを表示します。失敗一覧が空でも、アプリケーションが正しく応答していることを保証するわけではありません。ポート・応答・アプリケーションログを別途確認する必要がある場合があります。

実行状態と自動起動設定の違い

activeは現在実行中またはアクティブな状態と関連し、enabledは通常関連するターゲットに接続され、起動時に開始するよう設定されていることを意味します。現在activeのサービスがdisabledである場合や、enabledであっても現在起動に失敗していることがあります。staticユニットは別のインストールルールがないため直接enableできなくても、他のユニットの依存関係などで動作する場合があります。

コマンド	主に確認や変更を行うもの	注意点
`systemctl status NAME.service`	状態・最近のログ要約の確認	要約だけでは全てのログを代替できません
`systemctl is-active NAME.service`	現在のアクティブ状態の確認	自動起動設定は確認できません
`systemctl is-enabled NAME.service`	自動起動設定の確認	現在の実行状況は不明
`systemctl start / stop NAME.service`	今すぐ開始 / 停止	自動起動設定自体は変更しない
`systemctl enable / disable NAME.service`	自動起動接続の設定 / 解除	現在の実行状態をすぐに変更するコマンドではない

表のNAME.serviceはプレースホルダーであり、実際にインストールされているユニット名に置き換える必要があります。サーバーに接続するために使用するSSHサービスなどの必須ユニットを停止すると、リモート接続が切断される可能性があります。変更コマンドはサービスへの影響や復旧経路を確認した後にのみ実行してください。

読み取り専用コマンドでサービスを確認

次の systemd-journald.service は systemd 環境でよく見られるユニットですが、最小イメージや特殊な環境では結果が異なる場合があります。すべて照会コマンドです。

systemctl status systemd-journald.service
systemctl is-active systemd-journald.service
systemctl is-enabled systemd-journald.service

status はロード情報、現在の状態、実行プロセスおよび最近のログの一部を表示できます。is-active は active、inactive、failed などの結果を出力し、非アクティブ状態で 0 以外の終了状態を返すことがあります。is-enabled は enabled だけでなく disabled、static なども表示できます。static をすぐにエラーと判断しないでください。

サービスを変更する際に知っておくべきコマンド

実際に変更する際、start と stop は現在の状態に、enable と disable は自動起動設定にそれぞれ焦点を当てます。restart は一旦サービスを再起動するため、接続が切れたり作業が中断されることがあります。reload はサービスが対応している場合にのみ設定を再読み込みするよう要求し、動作の可否と範囲はサービスごとに異なります。enable --now は自動起動設定と即時起動の両方を要求します。

ユニットファイル自体を作成または変更した後には、systemd マネージャーが定義を再読込するために daemon-reload が必要な場合があります。これはアプリケーションプロセスを再起動する restart やアプリケーション設定を再読込する reload とは異なります。稼働中のサービスのユニット・設定変更には、まずバックアップとメンテナンス時間を確保してください。

journalctl で現在のブートのログを読む

systemd ジャーナルにはサービスやカーネルなど複数のソースのログが集まることがあります。-b は現在のブートに範囲を絞り、-u は指定したユニットのメッセージのみを選択します。-n 30 は直近30件を要求します。参照権限が不足していると一部のログが表示されない場合があり、その場合は許可された管理者アカウントや適切な権限で再確認する必要があります。

journalctl -b -u systemd-journald.service -n 30 --no-pager
journalctl -b -p warning -n 30 --no-pager
journalctl --list-boots

最初のコマンドは現在のブートで該当ユニットの最近の記録を、二つ目は警告以上の優先度の最近の記録を表示します。警告1行が即、障害原因という意味ではなく、発生時刻と前後の文脈を合わせて読む必要があります。--list-boots に前回ブートがない場合は、ジャーナル保持設定や保存スペースのポリシーにより過去ログが利用できない可能性があります。前回ブートを調査する際は、記録が実際に存在するかまず確認してください。

サービスが起動しないときの診断手順

問題が発生したユニットの正確な名前とパッケージのインストール状況を確認します。似た名前の他のサービスを推測して操作してはいけません。
systemctl statusでloaded、active、失敗理由の要約と最新の記録を確認します。
journalctl -b -uで同じ起動の該当ユニットのログを広く読みます。設定エラー、権限問題、ポート衝突、依存サービスの失敗など、実際のメッセージが指す原因を探します。
設定ファイルと必要なリソース・依存関係を確認し、変更前にバックアップを残します。ログの一行だけを見て権限を過度に緩めてはいけません。
原因を修正した後、サービスへの影響が許容されるタイミングで必要な操作だけを行い、is-activeおよび実際のアプリケーションの応答を確認します。

起動時間に問題がある場合、systemd-analyze critical-chainは重要な起動経路を確認するのに役立ちます。一方でsystemd-analyze blameの個別時間が長いという理由だけで、そのサービスが全体の起動遅延の原因であると断定してはいけません。並列実行と依存関係を合わせて解釈する必要があります。

公式ドキュメント

systemctl(1) マニュアルはユニットの状態と変更コマンドを、journalctl(1) マニュアルは起動・ユニット・優先度別のログ参照方法を説明します。systemd.unit(5) マニュアルでユニットと依存関係の詳細な意味を確認できます。

Linux