🎱

🔧 systemd とサービス管理の基礎：初心者から実務までしっかり理解するガイド

に公開
Linux
systemd
idea

📝 はじめに

Linux のサービス管理において最も中心的な存在となっているのが systemd です。現代の主要ディストリビューション（Ubuntu、Debian、Fedora、RHEL、CentOS Stream、openSUSE、Arch Linux など）が systemd を採用しており、サービスの起動・停止、ログ管理、自動起動設定、依存関係管理、システムブートシーケンスなど、OS の中核を担う多機能フレームワークとなっています。
本記事では、systemd の基礎概念から実用的なサービス管理方法、独自サービスの作成、トラブルシューティング、さらに systemd を深く理解するための補足知識まで幅広く解説します。初心者はもちろん、中級者や運用担当者の基礎強化にも役立つ内容に仕上げています。

🚀 1. systemd とは？ — Linux の心臓部を支える基盤

systemd（システムディー） は init システムの一種であり、従来の SysVinit の後継として設計されました。Linux の起動シーケンスやプロセス管理を大幅に改善し、サービス間の依存関係管理や高速起動を実現したモダンな仕組みです。

systemd が担う主要な役割（従来と比較して強化された点）

  • 高速で効率的な起動処理 → 並列起動でブート時間を短縮
  • サービスのライフサイクル管理（起動／停止／再起動／自動再起動）
  • 依存関係の明確化と制御（After / Requires / Wants）
  • ログ管理統合（journalctl） → /var/log だけでは把握しづらかったサービスごとのログを簡単に確認
  • タイマー機能（cronの代替） → systemd-timers により統一的に管理
  • ネットワーク・デーモン管理 → systemd-networkd、systemd-resolved
  • cgroups によるプロセス管理とリソース制御

systemd は単なる init の置き換えではなく、Linux システム全体の基盤として動作する巨大なコンポーネント体系です。

📦 2. Unit ファイルとは？ — systemd の最小構成要素を理解する

systemd ではサービスやスケジューリング、デバイス管理など、あらゆる機能を Unit（ユニット） という構成要素として扱います。Unit ファイルは systemd の設定を記述するための中心的な仕組みです。

主な Unit の種類

Unit 種類 説明 具体例
.service サービス（デーモン）の起動・停止定義 nginx.service, ssh.service
.socket ソケットを監視して必要時にサービスを起動（socket activation） cups.socket
.timer cron の代替機能、定期実行 backup.timer
.target 複数サービスの集合、ランレベルの代替 multi-user.target
.mount マウントポイント定義 data.mount
.device ハードウェアデバイス管理 sys-devices-*（デバイス階層に応じて自動生成されるユニット名）
.path ファイル変更を監視しトリガする myapp.path

Unit ファイルの配置場所と優先順位

systemd は複数のディレクトリを参照し、優先順位に基づいて設定を読み込みます：

  • /etc/systemd/system/ — 管理者が独自に追加・上書きする設定（最優先）
  • /usr/lib/systemd/system/ — パッケージが提供する公式設定
  • /run/systemd/system/ — 一時的な設定や自動生成ファイル

Unit の上書きには override.conf を使う方法が推奨されます：

sudo systemctl edit nginx

これにより安全にカスタマイズが可能です。

🛠️ 3. サービス管理の基本コマンド

systemctl は systemd を操作する主要コマンドです。

✔️ サービス状態の確認

systemctl status nginx.service
  • 現在の状態（active/inactive/failed）
  • 直近のログ
  • プロセス ID
  • ExecStart 情報など

✔️ 起動・停止・再起動

sudo systemctl enable nginx
sudo systemctl disable nginx
sudo systemctl is-enabled nginx

✔️ 実行中サービスの一覧

systemctl --type=service --state=running

✔️ サービスユニットの完全リスト

systemctl list-unit-files --type=service

🧩 4. systemd のログ管理：journalctl

systemd の journal は非常に強力なログ管理システムであり、サービスごとのログやシステム全体のログを一元管理できます。

基本的なログ確認

journalctl -u nginx

リアルタイム監視

journalctl -u nginx -f

カーネルログ

journalctl -k

時間を指定して絞り込み

journalctl --since "2024-01-01" --until "2024-01-02"

ブートごとの表示

journalctl -b 0   # 最新ブート
journalctl -b -1  # 1つ前のブート

ログ容量の管理

sudo journalctl --vacuum-size=500M
sudo journalctl --vacuum-time=30d

⚙️ 5. 独自 systemd サービスの作成

自作アプリやスクリプトを systemd サービスとして扱うことで、安定した起動、監視、自動再起動を行わせることができます。

最小限のサービス例

[Unit]
Description=My Custom App
After=network.target

[Service]
ExecStart=/usr/bin/python3 /home/user/myapp/app.py
Restart=always
User=user
WorkingDirectory=/home/user/myapp

[Install]
WantedBy=multi-user.target

daemon-reload の意味

sudo systemctl daemon-reload

Unit ファイルを変更した際は 必ず 実行しないと systemd が再読み込みしません。

サービスの有効化と起動

sudo systemctl enable --now myapp

（--now を付けると enable と start を同時に実行）

自動再起動の高度設定

Restart=on-failure
RestartSec=3

🧠 6. systemd の依存関係と Target

systemd は依存関係を正確に把握し、必要な順序でサービスを起動します。

依存関係の主なキーワード

  • After= — 起動順を定義
  • Requires= — 必須依存関係（無いと起動失敗）
  • Wants= — 任意依存関係（推奨）

Target の例

Target 説明
multi-user.target GUI を使用しないサーバー向けの通常動作モード。ネットワーク・サービスが稼働する。
graphical.target デスクトップ環境（GNOME / KDE / XFCE など）が起動するモード。一般的なデスクトップLinuxがここに到達する。
rescue.target root のみがログインできる最小限の環境。トラブル時の調査用。
emergency.target ほぼ何も起動しない完全最小環境。システムが壊れた際の最終手段。

Target は「サービスの集合体」であり、これを理解することで systemd の動作全体を把握できます。

🧯 7. よくあるトラブルと解決法

systemd を扱う上で頻繁に遭遇する問題と、その具体的な解決方法をまとめます。

❗ サービスが起動しない

まずはステータスとログを確認：

systemctl status myapp
journalctl -u myapp -xe

原因の例：

  • ExecStart のパスが間違っている
  • 権限不足（User=がファイルにアクセスできない）
  • 依存関係エラー（After/Requires が不足）

❗ Unit の変更が反映されない

→ daemon-reload を忘れている

sudo systemctl daemon-reload

❗ サービスがすぐ落ちる

→ RestartSec で待機時間を調整、ログで原因確認

Restart=on-failure
RestartSec=5

❗ 自動起動が有効になっているのに起動しない

systemctl is-enabled myapp
systemctl list-dependencies multi-user.target

依存関係が正しく設定されていない可能性があります。

🧩 8. systemd の周辺ツール：分析・可視化編

systemd は関連ツールも非常に強力です。

🔍 起動時間の分析（systemd-analyze）

systemd-analyze

→ 起動に要した時間を表示。

systemd-analyze blame

→ 起動が遅いサービスを一覧表示。

systemd-analyze critical-chain

→ ブートシーケンスの依存関係を可視化。

📊 ユニットの依存関係を可視化

systemd-analyze dot --to-pattern=myapp.service | dot -Tpng > myapp.png

Graphviz を使って依存関係の図を生成できます。

🧩 9. systemd timer（cron の進化版）超入門

systemd の timer は cron の代替として非常に優秀で、ログ管理や依存関係管理が統合されています。

例：毎日バックアップする timer

backup.timer
[Unit]
Description=Daily Backup Timer

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

backup.service と組み合わせて使用します。

sudo systemctl enable --now backup.timer

timer の一覧

systemctl list-timers

🧠 10. systemd の本質：Linux を制御する“統合基盤”

systemd を理解すると、Linux の動作全体が明確に見えるようになります。

  • OS 起動の流れ
  • サービスの依存関係
  • 自動起動の仕組み
  • ログ管理の統一化
  • タイマー・デバイス・ネットワーク・マウントの自動管理

特に systemd は構造が大きいため、最初は難しく感じますが、単語や概念を1つずつ理解していくことで確実に使いこなせるようになります。

🎯 まとめ

systemd は現代 Linux における中核的なサービス管理システムです。基本操作から独自サービスの作成、ログ管理、依存関係の理解まで身につけることで、Linux 運用は驚くほど楽になります。
この記事のポイント：

  • systemd は init 以上の“統合基盤”である
  • Unit ファイルの構造と種類が理解の起点
  • systemctl で起動・停止・自動起動を管理
  • journalctl でログを高速・正確に確認できる
  • 独自サービスを作成すれば自動化が進む
  • Target と依存関係を理解するとトラブル対処が速くなる
  • timer で cron より強力なスケジューリングが可能

systemd を理解することは、Linux を“ただ使う”から“使いこなす”段階へ進むための大きなステップです。ぜひこの知識を活用して、より洗練された Linux 運用を実現してください。 🚀

株式会社ONE WEDGE

【Serverlessで世の中をもっと楽しく】 ONE WEDGEはServerlessシステム開発を中核技術としてWeb系システム開発、AWS/GCPを利用した業務システム・サービス開発、PWAを用いたモバイル開発、Alexaスキル開発など、元気と技術力を武器にお客様に真摯に向き合う価値創造企業です。
https://onewedge.co.jp/

Discussion