systemdサービス管理【2026年7月更新】

Linuxシステムの安定稼働を支えるsystemdサービス管理で、サービスの起動・停止・再起動・ステータス確認を完全制覇しよう。本記事では、systemdの基本コマンドから実践的なトラブルシューティングまで、現場で即実践できるノウハウを網羅する。

目次

—

systemdサービス管理とは

Linuxシステムのサービス管理を一元化するsystemdは、従来のSysVinitに代わる現代的なinitシステムであり、2026年現在ではほぼ全ての主要Linuxディストリビューションで採用されています。systemdはサービスの起動・停止・再起動だけでなく、依存関係の管理、リソース制限、ログ管理まで包括的に担う統合プラットフォームです。

具体的には、以下の機能を提供します：

  • 並列起動：従来のinitシステムよりも高速なシステム起動
  • 依存関係自動解決：サービス間の依存関係を自動で管理
  • リソース制御：cgroupsを活用したCPU・メモリ制限
  • ログ管理：ジャーナルログシステム（journald）による統合ログ管理
  • デバイス管理：udevとの連携による動的デバイス管理

systemdが導入された背景には、サーバー環境の複雑化に伴い、従来のinitシステムでは対応しきれなくなったという技術的課題がありました。特に、大規模なサービス群を効率的に管理するニーズが高まったことが、systemd普及の原動力となっています。

（出典: systemd公式ドキュメント）

—

基本コマンド一覧

systemdサービス管理の基本となるコマンド群を、実用的な順に整理します。これらのコマンドは全てroot権限で実行する必要があります。

コマンド説明使用例備考
systemctl statusサービスの現在の状態を表示systemctl status nginxサービス名の自動補完が利用可能
systemctl startサービスを起動systemctl start postgresql依存関係のあるサービスも自動起動
systemctl stopサービスを停止systemctl stop apache2即時停止でデータ損失の可能性あり
systemctl restartサービスを再起動systemctl restart docker設定変更後の反映に使用
systemctl reload設定ファイルの再読み込みのみsystemctl reload sshdサービスを完全停止せずに設定反映
systemctl enableサービスを自動起動に設定systemctl enable mysqlシステム起動時に自動で起動
systemctl disableサービスの自動起動を解除systemctl disable cron手動起動のみ可能にする
systemctl is-activeサービスが稼働中か確認systemctl is-active sshステータス確認に特化したコマンド
systemctl list-units全てのサービスユニットを表示systemctl list-units –type=serviceフィルタリングが可能

これらのコマンドを組み合わせることで、サービスのライフサイクルを完全に制御できます。特に、systemctl enableとsystemctl startを同時に実行するsystemctl enable --nowは、サービスの自動起動設定と即時起動を一括で行えるため、非常に便利です。

—

サービスファイルの構造と作成

主要ディレクティブ解説

systemdのサービス管理は、.serviceファイルと呼ばれる設定ファイルによって定義されます。これらのファイルは通常/etc/systemd/system/または/usr/lib/systemd/system/に配置されます。

以下に、主要なディレクティブをカテゴリ別に整理します：

サービスの基本情報

ディレクティブ説明例
[Unit]サービスのメタ情報を定義Description=My Web Service
After=network.target
Descriptionサービスの説明文Description=Apache HTTP Server
After依存関係のあるサービスを指定After=network.target
Requires必須の依存関係を指定Requires=postgresql.service
Wants推奨される依存関係を指定Wants=redis.service

サービスの実行設定

ディレクティブ説明例
[Service]サービスの実行方法を定義Type=simple
ExecStart=/usr/sbin/nginx
Typeサービスの起動タイプを指定Type=simple（デフォルト）
Type=forking
Type=oneshot
Type=notify
ExecStartサービスの起動コマンドExecStart=/usr/bin/python3 /app/main.py
ExecStopサービスの停止コマンドExecStop=/usr/bin/kill -TERM $MAINPID
Restartサービスの再起動ポリシーRestart=always
Restart=on-failure
Restart=no
Userサービス実行時のユーザーUser=www-data
WorkingDirectory作業ディレクトリの指定WorkingDirectory=/var/www/html

サービスのリソース制御

ディレクティブ説明例
CPUQuotaCPU使用率の上限（%単位）CPUQuota=50%
MemoryLimitメモリ使用量の上限MemoryLimit=1G
TasksMaxプロセス数の上限TasksMax=1024

これらのディレクティブを適切に組み合わせることで、柔軟なサービス管理が可能になります。特に、Typeディレクティブはサービスの起動方法によって適切な値を設定する必要があり、間違った設定はサービスの起動失敗につながります。

実践的なサービスファイル例

以下に、実際のWebアプリケーションを想定したサービスファイルの例を示します。この例では、Python製のWebアプリケーションをsystemdで管理する方法を解説します。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE service SYSTEM "service.dtd">
<service>
  <!-- 基本情報 -->
  <id>my-webapp</id>
  <description>My Python Web Application</description>
  <after>network.target</after>
  <requires>postgresql.service</requires>

  <!-- サービス実行設定 -->
  <type>simple</type>
  <exec>
    <start>/usr/bin/python3 /opt/myapp/main.py</start>
    <stop>/usr/bin/kill -TERM $MAINPID</stop>
    <restart>always</restart>
  </exec>

  <!-- ユーザーと権限 -->
  <user>appuser</user>
  <group>appgroup</group>
  <working-directory>/opt/myapp</working-directory>

  <!-- リソース制御 -->
  <cpu-quota>20%</cpu-quota>
  <memory-limit>512M</memory-limit>
</service>

このサービスファイルのポイント：

  1. Type=simple：アプリケーションがバックグラウンドで動作することを前提としています
  2. Requires=postgresql.service：データベースサービスに依存します
  3. Restart=always：サービスがクラッシュしても自動で再起動します
  4. CPUQuota=20%：CPU使用率を20%に制限します
  5. MemoryLimit=512M：メモリ使用量を512MBに制限します

サービスファイルを作成したら、以下の手順でsystemdに反映します：

  1. ファイルを/etc/systemd/system/に配置します
  2. sudo systemctl daemon-reloadでsystemdに設定を再読み込みさせます
  3. sudo systemctl enable --now my-webappで自動起動を有効化し、即時起動します
—

サービス管理の実践テクニック

依存関係の管理

systemdにおける依存関係管理は、サービスの安定稼働に不可欠です。依存関係には大きく分けて2種類あります：

強制的依存関係（Requires）

サービスが完全に動作するために必須の依存関係です。依存サービスが失敗すると、主サービスも失敗します。

[Unit]
Description=My Application
Requires=database.service
After=database.service

推奨的依存関係（Wants）

サービスの動作に有用だが必須ではない依存関係です。依存サービスが失敗しても主サービスは起動します。

[Unit]
Description=My Application
Wants=cache.service
After=cache.service

依存関係のトラブルシューティング

依存関係に関する問題が発生した場合は、以下のコマンドで詳細を確認できます：

  • systemctl list-dependencies <サービス名>：依存関係ツリーを表示
  • journalctl -u <サービス名> -b：サービスの起動ログを確認
  • systemctl show <サービス名>：サービスの詳細な状態を表示

依存関係の設定ミスで最も多いケースは、AfterディレクティブとRequires/Wantsディレクティブの不一致です。例えば、After=network.targetを設定しても、Requires=network.targetを設定しないと、ネットワークが完全に準備できていない状態でサービスが起動する可能性があります。

タイマー機能の活用

systemdのタイマー機能を使用すると、定期的なジョブ実行をsystemdで管理できます。従来のcronに代わる機能として注目されています。

タイマー機能には2つのファイルが必要です：

  1. .timerファイル：実行スケジュールを定義
  2. .serviceファイル：実際のジョブを定義

以下に、毎日午前3時に実行されるバックアップジョブの例を示します：

backup.timer（実行スケジュール定義）

[Unit]
Description=Daily Backup Timer

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

backup.service（ジョブ定義）

[Unit]
Description=Daily Backup Service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

タイマーを有効化するには：

  1. 両方のファイルを/etc/systemd/system/に配置
  2. sudo systemctl daemon-reloadでsystemdに認識させる
  3. sudo systemctl enable --now backup.timerでタイマーを有効化

タイマー機能の利点：

  • cronと異なり、systemdの依存関係管理と統合可能
  • サービスのステータス管理が容易
  • 時刻指定が柔軟（例：OnCalendar=Mon..Fri 09:00）

cgroupsとの連携

systemdはLinuxカーネルのcgroups（コントロールグループ）機能を活用して、サービスごとのリソース制御を実現しています。cgroupsを使用すると、CPU、メモリ、I/O、ネットワーク帯域などのリソースをサービスごとに制限できます。

systemdにおけるcgroupsの主な利点：

  • サービスごとのリソース使用量の可視化
  • リソース制限の自動適用
  • サービスの異常時におけるリソースリーク防止

cgroupsを活用したリソース制御の例：

[Unit]
Description=Resource Limited Service

[Service]
Type=simple
ExecStart=/usr/bin/myapp
CPUQuota=50%
MemoryLimit=1G
TasksMax=1024
OOMScoreAdjust=-500

この設定では：

  • CPUQuota=50%：CPU使用率を50%に制限
  • MemoryLimit=1G：メモリ使用量を1GBに制限
  • TasksMax=1024：プロセス数を1024に制限
  • OOMScoreAdjust=-500：OOM Killerによる強制終了を回避

リソース使用量の確認方法：

  • systemd-cgtop：リアルタイムのリソース使用量を表示
  • systemctl status <サービス名>：サービスのリソース制限状態を表示
  • cat /sys/fs/cgroup/memory/system.slice/<サービス名>/memory.usage_in_bytes：メモリ使用量を確認
—

トラブルシューティング完全ガイド

systemdサービス管理におけるトラブルシューティングは、ログ分析とシステム状態の確認から始まります。以下に、一般的なトラブルとその解決策を網羅的に解説します。

サービスが起動しない

最も一般的なトラブルの1つです。以下の手順で原因を特定します：

  1. ステータス確認
    systemctl status <サービス名>

    このコマンドでサービスの状態、エラーメッセージ、依存関係の状態を確認します。

  2. ログ確認
    journalctl -u <サービス名> -b

    サービス固有のログを確認します。-bオプションでシステム起動以降のログのみ表示します。

  3. 依存関係確認
    systemctl list-dependencies <サービス名>

    依存関係のツリー構造を確認し、問題のある依存関係を特定します。

  4. 手動実行テスト
    sudo -u <ユーザー名> <ExecStartコマンド>

    サービスファイルのExecStartコマンドを手動で実行し、エラーを確認します。

一般的な原因と解決策：

  • ファイルパーミッション不足：chmodやchownで適切な権限を設定
  • 依存サービスの未起動：依存サービスを起動または有効化
  • 設定ファイルの不正：設定ファイルの構文エラーを修正
  • リソース不足：MemoryLimitやCPUQuotaを調整
  • 競合するサービス：Conflicts=ディレクティブで競合を明示

サービスが頻繁に再起動する

サービスが予期せず再起動を繰り返す場合は、以下の原因が考えられます：

  1. 設定ミス
    • Restart=alwaysが設定されているが、サービスが正常に起動していない
    • Type=forkingなのに、PIDFile=が正しく設定されていない
  2. リソース不足
    • メモリリークによりOOM Killerがサービスを強制終了
    • CPU使用率がCPUQuotaを超過
  3. 外部要因
    • ネットワーク接続の不安定さ
    • 外部サービス（データベース、API）の応答不良

解決策：

  • Restart=noに変更して手動で再起動を制御
  • RestartSec=で再起動までの待機時間を延長
  • MemoryLimitやCPUQuotaを増加
  • サービスのログを詳細に分析し、根本原因を特定

サービスがメモリリークを起こす

メモリリークはサービスの安定稼働を脅かす重大な問題です。systemdでは以下の方法でメモリ使用量を監視・制御できます：

  1. メモリ使用量の監視
    systemctl status <サービス名>
journalctl -u <サービス名> -b | grep -i memory

    サービスの現在のメモリ使用量と履歴を確認します。

  2. OOM Killerの設定
    OOMScoreAdjust=-500

    この設定で、OOM Killerによる強制終了を回避します。値は-1000（最も回避）から1000（最も優先的に終了）まで調整できます。

  3. メモリ制限の設定
    MemoryLimit=1G
MemorySwapMax=512M

    メモリ使用量の上限とスワップ領域の上限を設定します。

  4. メモリダンプの取得
    sudo coredumpctl list
sudo coredumpctl info <PID>

    サービスがクラッシュした際にメモリダンプを取得し、解析します。

メモリリークの一般的な原因：

  • 未解放のメモリ領域（C/C++の場合）
  • 循環参照（Python、JavaScriptなど）
  • グローバル変数の過剰な使用
  • サードパーティライブラリのメモリ管理不備

サービスの起動が遅い

サービスの起動が遅い場合は、以下の要因を検討します：

  1. 依存関係の待ち時間
    • After=で指定された依存サービスの起動が完了するまで待機
    • 解決策：After=の順序を見直す、またはWants=に変更
  2. 外部サービスへの依存
    • データベースやAPIへの接続待ち
    • 解決策：接続タイムアウトの設定、リトライロジックの実装
  3. ディスクI/Oのボトルネック
    • 大量のファイル読み込みや書き込み
    • 解決策：IOSchedulingClass=idleで優先度を下げる
  4. サービス自体の起動処理
    • 不要な初期化処理の実行
    • 解決策：起動処理の最適化、遅延読み込みの実装

起動時間の計測方法：

systemd-analyze blame
systemd-analyze critical-chain <サービス名>

これらのコマンドで、システム全体および特定サービスの起動にかかる時間を分析できます。

—

よくある質問と回答

Q1: systemdとS…

A1: systemdとSysVinitの主な違いは以下の通りです：

  • 起動速度：systemdは並列起動によりSysVinitよりも高速（出典: LWN記事）
  • 機能統合：systemdはinitシステムだけでなく、udev、cron、syslogなどの機能を統合
  • 依存関係管理：systemdは自動的に依存関係を解決し、サービスの起動順序を最適化
  • リソース制御：cgroupsを活用したCPU・メモリ制限が可能
  • ログ管理：journaldによる統合ログ管理

Q2: systemdサー…

A2: 自動起動を無効にするには以下のコマンドを実行します：

sudo systemctl disable <サービス名>

これにより、システム起動時の自動起動が解除されます。自動起動を再度有効にするには：

sudo systemctl enable <サービス名>

Q3: systemdサー…

A3: サービスファイルを変更した後は、以下の手順で変更を反映します：

  1. サービスファイルを編集
  2. sudo systemctl daemon-reload：systemdに設定の再読み込みを指示
  3. sudo systemctl restart <サービス名>：サービスを再起動して変更を反映

注意：daemon-reloadを実行しないと、変更が反映されません。これはsystemdがサービスファイルのキャッシュを保持しているためです。

Q4: systemdサー…

A4: 環境変数は以下の方法で設定できます：

  1. サービスファイルに直接記述
    [Service]
Environment="PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Environment="DATABASE_URL=postgres://user:pass@localhost/db"
  2. 環境変数ファイルを使用
    [Service]
EnvironmentFile=/etc/myapp/env.conf

    このファイルにはVAR_NAME=value形式で環境変数を記述します。

  3. systemd-drop-inを使用
    sudo mkdir -p /etc/systemd/system/<サービス名>/override.conf.d
sudo systemctl edit <サービス名>

    これにより、既存のサービスファイルを上書きせずに設定を追加できます。

Q5: systemdサー…

A5: User=およびGroup=ディレクティブを使用します：

[Service
 【編集・制作ポリシー】
 本記事はRoute Bloom編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前に必ずテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。
ABOUT ME
たから
サラリーマンをしながら開業して経営やってます。
今年、本業で独立・別事業を起業予定です。
◆経験：IT講師/インフラエンジニア/PM/マネジメント/採用/運用・保守・構築・設計
◆取得資格：CCNA/CCNP/LPIC-1/AZ-900/FE/サーティファイC言語
◆サイドビジネス：アパレル事業/複数のWEBメディアを運営