systemdサービス管理徹底解説【2026年最新】
systemdサービス管理徹底解説【2026年最新】
Linuxシステムの安定稼働を支えるsystemdサービス管理の完全ガイドです。サービスの起動・停止・再起動・有効化・無効化を自在に操る技術を、実務で即活用できる形で解説します。本記事で紹介するコマンドと設定方法を実践すれば、サーバー管理の生産性が飛躍的に向上します。
目次
systemdサービス管理…
systemdとは何か、そ…
サービス管理の基本概念：ユ…
systemdサービス管理…
サービスの起動・停止・再起…
サービスの有効化・無効化と…
サービスのトラブルシューテ…
systemdサービスの高…
カスタムサービスの作成と設…
サービスの依存関係と順序制…
systemdタイマーを活…
systemdサービス管理…
一般的なエラーとその解決方法
サービス起動失敗時の診断手順
リソース制限とサービスの安…
まとめ：systemdサー…
—systemdサービス管理…
systemdとは何か、そ…
systemdは、Linuxシステムの起動・サービス管理・デバイス管理・ログ管理などを一元的に行う init システムです。2010年にリリースされて以来、主要なLinuxディストリビューションで採用されており、現在ではUbuntu、CentOS、RHEL、Debianなどで標準的に使用されています。
systemdが提供する主なメリットは以下の通りです：
| メリット | 説明 | 従来のsysvinitとの比較 |
|---|---|---|
| 高速な起動 | 並列起動により起動時間を大幅に短縮 | 従来は逐次起動で時間がかかっていた |
| 依存関係管理 | サービス間の依存関係を自動的に解決 | 手動で依存関係を設定する必要があった |
| 統合ログ管理 | journalctlコマンドでリアルタイムにログ確認可能 | ログは別ファイルで管理されていた |
| リソース制御 | CPU・メモリ・I/Oの制限設定が可能 | 制限機能が限定的だった |
| サービス管理の一元化 | すべてのサービスをsystemctlで統一的に管理 | 各サービスで異なる管理方法が必要だった |
systemdが採用されるようになった背景には、Linuxシステムの複雑化とサーバー環境の多様化があります。従来のsysvinitでは、サービスの並列起動ができず、起動時間が長くなるという課題がありました。systemdはこれらの課題を解決し、現代のLinuxシステムに不可欠な基盤技術となっています。
（出典: systemd公式ドキュメント）
サービス管理の基本概念：ユ…
systemdのサービス管理を理解する上で、以下の3つの基本概念を押さえることが重要です：
1. ユニット（Unit）
systemdにおけるサービス管理の基本単位が「ユニット」です。ユニットには以下の種類があります：
- サービスユニット（.service）：実際のサービスを管理するユニット
- ソケットユニット（.socket）：ソケットベースの起動を管理
- ターゲットユニット（.target）：複数のユニットをグループ化
- マウントユニット（.mount）：ファイルシステムのマウントを管理
- デバイスユニット（.device）：デバイスの検出と管理
最も一般的に使用されるのがサービスユニットです。例えば、WebサーバーのApacheを管理する場合は「httpd.service」というサービスユニットが使用されます。
2. ターゲット（Target）
ターゲットは、システムの状態を定義するユニットです。主なターゲットには以下があります：
| ターゲット名 | 用途 | 対応する従来のランレベル |
|---|---|---|
| multi-user.target | マルチユーザーのテキストモード起動 | ランレベル3 |
| graphical.target | グラフィカル環境の起動 | ランレベル5 |
| rescue.target | レスキューモード（シングルユーザー） | ランレベル1 |
| emergency.target | 緊急モード | 該当なし |
| shutdown.target | システムシャットダウン | 該当なし |
例えば、グラフィカル環境でシステムを起動したい場合は「graphical.target」を使用します。ターゲットは依存関係を持つことができ、他のユニットをグループ化して管理します。
3. 依存関係（Dependency）
systemdでは、サービス間の依存関係を明示的に定義できます。主な依存関係の種類には以下があります：
- Requires：必須の依存関係。指定したサービスが失敗すると依存元も失敗
- Wants：弱い依存関係。指定したサービスが失敗しても依存元は継続
- After：起動順序の制御。指定したサービスの後に起動
- Before：起動順序の制御。指定したサービスの前に起動
- Conflicts：競合関係。指定したサービスと同時に起動できない
これらの依存関係を適切に設定することで、サービスの起動順序や障害時の動作を制御できます。例えば、データベースサービスが起動してからWebサーバーを起動するように設定することができます。
—systemdサービス管理…
サービスの起動・停止・再起…
systemdサービスの基本的な操作はすべてsystemctlコマンドで行います。以下に主要な操作とそのコマンドを紹介します。
1. サービスの起動
サービスを起動するには以下のコマンドを使用します：
sudo systemctl start サービス名.service例えば、Apache HTTP Serverを起動する場合：
sudo systemctl start httpd.service起動に成功すると、サービスはアクティブな状態になります。起動中のサービスはactive (running)と表示されます。
2. サービスの停止
サービスを停止するには以下のコマンドを使用します：
sudo systemctl stop サービス名.service例えば、Apache HTTP Serverを停止する場合：
sudo systemctl stop httpd.service停止に成功すると、サービスは非アクティブな状態になります。
3. サービスの再起動
サービスを再起動するには以下のコマンドを使用します：
sudo systemctl restart サービス名.service再起動は、サービスを停止してから再度起動する処理です。設定ファイルを変更した後に反映させる場合などに使用します。
例えば、Apache HTTP Serverを再起動する場合：
sudo systemctl restart httpd.service4. サービスのステータス確認
サービスの現在の状態を確認するには以下のコマンドを使用します：
systemctl status サービス名.service例えば、Apache HTTP Serverのステータスを確認する場合：
systemctl status httpd.serviceこのコマンドを実行すると、以下のような情報が表示されます：
- サービスの現在の状態（active, inactive, failedなど）
- プロセスID（PID）
- 起動にかかった時間
- 最近のログメッセージ
- 依存関係の状態
ステータス確認はトラブルシューティングの第一歩として非常に重要です。サービスが正常に動作していない場合は、まずsystemctl statusで状態を確認しましょう。
5. サービスの一覧表示
システム上のすべてのサービスを一覧表示するには以下のコマンドを使用します：
systemctl list-units --type=serviceこのコマージュを実行すると、すべてのサービスとその状態が一覧表示されます。表示される情報には以下が含まれます：
- UNIT：サービス名
- LOAD：設定ファイルの読み込み状態
- ACTIVE：サービスのアクティブ状態
- SUB：サービスのサブ状態
- DESCRIPTION：サービスの説明
特定の状態のサービスのみを表示することもできます。例えば、失敗したサービスのみを表示する場合：
systemctl list-units --type=service --state=failed6. サービスの有効化と無効化
サービスの有効化と無効化については、次のセクションで詳しく解説します。
サービスの有効化・無効化と…
systemdにおける「有効化」と「無効化」は、サービスの自動起動設定を制御する重要な機能です。これらはシステムの起動時にサービスが自動的に起動するかどうかを決定します。
1. サービスの有効化（自動起動設定）
サービスを有効化することで、システム起動時に自動的にサービスが起動するように設定できます。有効化するには以下のコマンドを使用します：
sudo systemctl enable サービス名.service例えば、Apache HTTP Serverを有効化する場合：
sudo systemctl enable httpd.service有効化に成功すると、以下のようなメッセージが表示されます：
Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.このメッセージは、httpd.serviceがmulti-user.targetの起動時に自動的に起動するように設定されたことを示しています。
有効化されたサービスは、systemctl is-enabledコマンドで確認できます：
systemctl is-enabled httpd.serviceこのコマンドはenabledと表示されれば、有効化されていることを示します。
2. サービスの無効化（自動起動設定の解除）
サービスを無効化することで、システム起動時の自動起動を停止します。無効化するには以下のコマンドを使用します：
sudo systemctl disable サービス名.service例えば、Apache HTTP Serverを無効化する場合：
sudo systemctl disable httpd.service無効化に成功すると、以下のようなメッセージが表示されます：
Removed /etc/systemd/system/multi-user.target.wants/httpd.service.このメッセージは、httpd.serviceがmulti-user.targetの起動時に自動起動しないように設定されたことを示しています。
無効化されたサービスは、systemctl is-enabledコマンドでdisabledと表示されます。
3. サービスのマスキング（完全な無効化）
サービスを完全に無効化するには「マスキング」という機能を使用します。マスキングされたサービスは、手動で起動することも、他のサービスから起動されることもありません。
マスキングするには以下のコマンドを使用します：
sudo systemctl mask サービス名.service例えば、Apache HTTP Serverをマスキングする場合：
sudo systemctl mask httpd.serviceマスキングに成功すると、以下のようなメッセージが表示されます：
Created symlink /etc/systemd/system/httpd.service → /dev/null.マスキングされたサービスは、systemctl is-enabledコマンドでmaskedと表示されます。
マスキングを解除するには以下のコマンドを使用します：
sudo systemctl unmask サービス名.serviceマスキングは、特定のサービスがシステムに与える影響を完全に排除したい場合に使用します。例えば、セキュリティ上の理由で特定のサービスを完全に無効化したい場合などに有効です。
4. サービスの再読み込み
サービスの設定ファイルを変更した後は、systemdに設定の再読み込みを通知する必要があります。再読み込みするには以下のコマンドを使用します：
sudo systemctl daemon-reloadこのコマンドは、新しく追加・削除・変更されたサービス設定ファイルを再読み込みします。設定ファイルを編集した後に必ず実行してください。
5. サービスのリロード
一部のサービスでは、設定ファイルを変更した後にサービス自体をリロードすることで、設定を反映させることができます。リロードするには以下のコマンドを使用します：
sudo systemctl reload サービス名.service例えば、Apache HTTP Serverの設定をリロードする場合：
sudo systemctl reload httpd.serviceリロードがサポートされているサービスでは、設定ファイルの変更を反映させるためにreloadコマンドを使用します。リロードがサポートされていないサービスではrestartコマンドを使用する必要があります。
サービスのトラブルシューテ…
systemdサービスのトラブルシューティングでは、ログの確認が最も重要な作業の一つです。systemdはjournaldと呼ばれる統合ログシステムを使用しており、journalctlコマンドでリアルタイムにログを確認できます。
1. journalctlコマンドの基本的な使い方
journalctlコマンドの基本的な使い方を以下に示します：
- すべてのログを表示：
journalctl - 直近のログを表示：
journalctl -n 50（直近50行） - リアルタイムにログを表示：
journalctl -f - 特定のサービスのログを表示：
journalctl -u サービス名.service - 特定の時間範囲のログを表示：
journalctl --since "2024-01-01 00:00:00" --until "2024-01-02 00:00:00" - エラーログのみを表示：
journalctl -p err - ブートごとのログを表示：
journalctl -b
2. サービス固有のログ確認
特定のサービスのログを確認するには、-uオプションを使用します。例えば、Apache HTTP Serverのログを確認する場合：
journalctl -u httpd.serviceこのコマンドを実行すると、Apache HTTP Serverに関連するすべてのログが表示されます。ログには以下のような情報が含まれます：
- サービスの起動・停止時刻
- エラーや警告メッセージ
- プロセスID（PID）
- リクエスト処理に関する情報
3. ログのフィルタリング
journalctlコマンドでは、ログをさまざまな条件でフィルタリングできます。以下に主なフィルタリングオプションを示します：
| オプション | 説明 | 使用例 |
|---|---|---|
| -p, –priority | ログレベルでフィルタリング | journalctl -p err（エラーレベル以上のログ） |
| –since, –until | 時間範囲でフィルタリング | journalctl --since "1 hour ago" |
| -S, –since | 開始時刻を指定 | journalctl -S "2024-01-01 00:00:00" |
| -U, –until | 終了時刻を指定 | journalctl -U "2024-01-02 00:00:00" |
| –grep | メッセージ内容でフィルタリング | journalctl --grep "error" |
これらのオプションを組み合わせることで、特定の条件に合致するログのみを効率的に確認できます。
4. ログの出力形式の変更
journalctlコマンドでは、ログの出力形式を変更できます。以下に主な出力形式オプションを示します：
--no-pager：ページャを使用せずに直接出力-o cat：簡潔な形式で出力-o json：JSON形式で出力-o json-pretty：整形されたJSON形式で出力-o short：短い形式で出力-o verbose：詳細な形式で出力
例えば、JSON形式でApache HTTP Serverのログを出力する場合：
journalctl -u httpd.service -o json5. ログの永続化設定
デフォルトでは、journaldはログをメモリ上に保持します。システムを再起動すると、ログは失われます。ログを永続化するには、設定ファイルを編集する必要があります。
ログを永続化するには、以下の手順を実行します：
/etc/systemd/journald.confファイルを編集します。- 以下の行を追加または編集します：
[Journal]
Storage=persistent- systemdを再起動します：
sudo systemctl restart systemd-journaldこの設定により、ログは/var/log/journal/ディレクトリに保存され、システム再起動後もログが維持されます。
6. 一般的なサービスエラーとその対処法
systemdサービスのトラブルシューティングでよく遭遇するエラーとその対処法を以下に示します：
| エラー | 原因 | 対処法 |
|---|---|---|
| Failed to start service | サービスの起動に失敗 | journalctlでログを確認し、設定ファイルや依存関係を確認 |
| Unit not found | 指定したサービスが存在しない | サービス名が正しいか確認。存在しない場合はサービスをインストール |
| Dependency failed | 依存関係のサービスが失敗 | 依存関係のサービスのステータスを確認し、修正 |
| Permission denied | 権限不足 | sudoを使用するか、適切な権限を設定 |
| Resource temporarily unavailable | リソース不足 | システムリソース（CPU、メモリ、ディスク）を確認 |
これらのエラーに対処する際は、まずsystemctl statusとjournalctlで詳細な情報を収集し、エラーの原因を特定します。その後、原因に応じた対処法を実施します。
systemdサービスの高…
カスタムサービスの作成と設…
systemdを活用する上で、カスタムサービスを作成する技術は非常に重要です。カスタムサービスを作成することで、独自のアプリケーションやスクリプトをsystemdの管理下に置き、自動起動や依存関係の管理などの機能を活用できます。
1. カスタムサービスの基本構造
カスタムサービスは、.serviceファイルとして定義します。このファイルは通常/etc/systemd/system/ディレクトリに配置します。以下に基本的な.serviceファイルの構造を示します：
[Unit]
Description=説明文
After=依存するサービス名.service
Requires=必須の依存サービス名.service
[Service]
Type=サービスタイプ
ExecStart=/path/to/start/script
ExecStop=/path/to/stop/script
Restart=リスタートポリシー
User=実行ユーザー
Group=実行グループ
WorkingDirectory=/作業ディレクトリ
[Install]
WantedBy=ターゲット名.target各セクションの詳細は以下の通りです：
[Unit]セクション
- Description：サービスの説明文
- After：起動順序の制御。指定したサービスの後に起動
- Before：起動順序の制御。指定したサービスの前に起動
- Requires：必須の依存関係。指定したサービスが失敗すると依存元も失敗
- Wants：弱い依存関係。指定したサービスが失敗しても依存元は継続
- Conflicts：競合関係。指定したサービスと同時に起動できない
[Service]セクション
- Type：サービスタイプ（後述）
- ExecStart：サービスの起動コマンド
- ExecStop：サービスの停止コマンド
- Restart：リスタートポリシー（後述）
- User：サービスを実行するユーザー
- Group：サービスを実行するグループ
- WorkingDirectory：作業ディレクトリ
- Environment：環境変数の設定
- StandardOutput：標準出力の処理方法
- StandardError：標準エラーの処理方法
[Install]セクション
- WantedBy：サービスを有効化した際にリンクされるターゲット
- Alias：サービスの別名
2. サービスタイプ（Type）
サービスタイプは、サービスの起動方法とプロセス管理方法を定義します。主なサービスタイプには以下があります：
| タイプ | 説明 | 使用例 |
|---|---|---|
| simple | デフォルトのタイプ。ExecStartで指定したプロセスがフォアグラウンドで起動 | Webサーバー、アプリケーションサーバー |
| forking | デーモンプロセスのようにforkしてバックグラウンドで起動 | 従来のデーモンプロセス |
| oneshot | 一度だけ実行されるタスク | 初期化スクリプト、バッチ処理 |
| dbus | D-Busサービス。D-Bus経由で他のプロセスと通信 | D-Busベースのサービス |
| notify | サービスが起動完了したことをsystemdに通知 | 起動完了を待つ必要があるサービス |
| idle | 他のジョブが完了した後に実行 | システムリソースを消費するジョブ |
例えば、Pythonで書かれたWebアプリケーションをsystemdで管理する場合、通常はsimpleタイプを使用します：
[Service]
Type=simple
ExecStart=/usr/bin/python3 /path/to/app.py
WorkingDirectory=/path/to/app
User=appuser
Group=appgroup一方、従来のデーモンプロセスのようにforkしてバックグラウンドで起動する場合はforkingタイプを使用します：
[Service]
Type=forking
ExecStart=/usr/sbin/daemon --daemonize
PIDFile=/var/run/daemon.pid3. リスタートポリ 【編集・制作ポリシー】
本記事はRoute Bloom編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前に必ずテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。ABOUT ME
本記事はRoute Bloom編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前に必ずテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。
