Linuxのsystemd入門｜サービス管理・ユニットファイルの書き方を現役講師が解説

※本記事はプロモーションを含みます。

systemdとは何か

Linux システムにおいて、systemd はオペレーティングシステムの起動後、各種サービス（Apache、Nginx、PostgreSQL、Docker など）やプロセスを統一的に管理するシステムマネージャとされています。従来の init システムに代わり、2015 年以降ほぼすべてのメジャーな Linux ディストリビューション（Red Hat、Debian、Ubuntu など）で標準採用されています。

systemd は以下の 3 つの主要な役割を担当します。

サービスの起動・停止・自動起動管理
複数サービス間の依存関係解決と起動順序制御
systemd-journald による統一的なログ管理（journalctl コマンド経由でのアクセス）

「自動起動設定したはずなのに再起動後に動いていない」「サービスが起動直後にクラッシュする」といったトラブルの多くは、systemd の動作原理と unit ファイルの記述ルールを正しく理解することで解決できます。本記事では systemctl コマンドの基本操作からカスタム unit ファイルの作成まで、インフラエンジニアが現場で実際に使う知識を解説します。【読了時間目安：約 8～10 分】

systemctl の基本操作

5 つの基本コマンド

systemctl は systemd を管理するメインコマンドです。最も使用頻度の高い 5 つの操作は以下の通りとされています。

コマンド	動作	用途
systemctl start [サービス名]	サービスを即時起動	手動での起動・再起動
systemctl stop [サービス名]	サービスを即時停止	メンテナンス・トラブル対応
systemctl enable [サービス名]	OS 起動時の自動起動を有効化	本番環境での永続化
systemctl disable [サービス名]	自動起動を無効化	サービス廃止・一時的な無効化
systemctl status [サービス名]	サービス状態と直近ログを表示	動作確認・トラブル初期診断

便利なオプション

上記の基本操作に加えて、スクリプトやシステム管理を効率化するコマンドも重要です。

systemctl restart [サービス名] — サービスを停止してから起動（ダウンタイムあり）
systemctl reload [サービス名] — 設定ファイルをリロード（サービスを停止しない）
systemctl is-active [サービス名] — アクティブ状態を出力（スクリプト向け）
systemctl daemon-reload — unit ファイル変更後に必ず実行。新しい設定を systemd に認識させる
systemctl list-units --type=service — システム内の全サービス一覧を表示

重要な注意点： unit ファイルを編集または新規作成した後は、必ず systemctl daemon-reload を実行してから systemctl start や systemctl enable を行う必要があります。この手順を忘れると、新しい設定が反映されず「enableしたのに自動起動しない」といった問題が発生する可能性があります。

Unit ファイルの構造と作成

Unit ファイルの配置

systemd で管理するサービスやシステム設定は「unit」と呼ばれる単位で定義されます。Unit ファイルは以下の場所に配置されるとされています。

/etc/systemd/system/ — カスタム unit ファイル（管理者が作成・編集）
/lib/systemd/system/ — OS やパッケージが提供するデフォルト unit ファイル
/run/systemd/system/ — 実行時に動的に生成される unit ファイル

独自のアプリケーションやカスタムサービスを systemd 管理下に置く場合は、/etc/systemd/system/ 配下に unit ファイルを作成します。

Service ユニットの…

Service 型の unit ファイルは以下の 3 つのセクションから構成されるとされています。

[Unit] セクション

サービス全体の説明と依存関係を記述します。

Description= — サービスの説明（systemctl status で表示される）
After= — 他のサービスより後で起動する（例：After=network.target はネットワーク起動後に起動）
Before= — 他のサービスより前に起動する
Requires= — 依存サービス（依存先が起動しないと自分も起動失敗）
Wants= — 推奨依存（依存先が失敗しても自分は起動）

[Service] セクション

実際のプロセス実行に関する設定を記述します。

Type= — プロセスタイプ（simple / forking / oneshot など）
User= — 実行ユーザー
WorkingDirectory= — 作業ディレクトリ
ExecStart= — サービス起動時に実行するコマンド
Restart= — 終了時の再起動ポリシー（on-failure / always など）
RestartSec= — 再起動までの待機秒数
StandardOutput= — 標準出力の出力先（journal / null など）

[Install] セクション

unit の有効化・無効化時の動作を定義します。

WantedBy= — このサービスをどのターゲットに属させるか（例：WantedBy=multi-user.target）
RequiredBy= — 依存サービスが起動時にこのサービスを必須とする

実践的な例

以下は Python アプリケーションを systemd で管理する実例です。

[Unit]
Description=My Python Application
After=network.target

[Service]
Type=simple
User=appuser
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/python3 /opt/myapp/main.py
Restart=on-failure
RestartSec=5
StandardOutput=journal

[Install]
WantedBy=multi-user.target

このファイルを /etc/systemd/system/myapp.service に保存した後、以下のコマンドで有効化します。

sudo systemctl daemon-reload
sudo systemctl enable --now myapp

--now オプションにより、enable と同時に即座に起動します。

ログ確認と監視

journalctl コマンド

systemd-journald は systemd の統一ログシステムです。journalctl コマンドでサービスのログを取得できるとされています。

コマンド	用途
`journalctl -u nginx`	nginx サービスのログを全件表示
`journalctl -u nginx -f`	リアルタイムでログを追跡（tail -f 相当）
`journalctl -u nginx --since today`	今日のログのみ表示
`journalctl -p err`	ERROR レベル以上のログのみ表示
`journalctl --disk-usage`	ジャーナルのディスク使用量を確認
`journalctl --vacuum-time=7d`	7 日以上前のログを削除

ログレベルの理解

systemd では以下の 8 段階のログレベルが定義されています。

emerg — 緊急（システム使用不可）
alert — アラート（即座の対応が必要）
crit — 重大
err — エラー
warning — 警告
notice — 通知
info — 情報
debug — デバッグ情報

journalctl -p warning -u [サービス名] とすることで、警告レベル以上のログのみを抽出できます。

トラブルシューティング

よくある問題と対処

問題 1：enable したのに自動起動しない

以下の 2 つの可能性が高いとされています。

systemctl daemon-reload を実行せずに unit ファイルを編集した場合
Unit ファイルに [Install] セクションがない、または WantedBy の値が不正な場合

対処法：

sudo systemctl daemon-reload
sudo systemctl enable [サービス名]
sudo systemctl is-enabled [サービス名] ← 「enabled」が返されることを確認

問題 2：サービスが起動直後にクラッシュする

以下の項目をチェックするとされています。

ExecStart に指定されたバイナリパスが正しいか
実行ユーザーが必要なディレクトリへのアクセス権限を持っているか
Type の値が適切か（特に Type=simple の場合）

診断コマンド：

systemctl status [サービス名]
journalctl -u [サービス名] -n 30 ← 直近 30 行のログを表示

問題 3：Type=simple 指定で無限再起動

アプリケーションが明示的にバックグラウンドへ fork する場合、Type=simple では systemd がプロセス終了を検知して即座に再起動します。この場合 Type=forking に変更する必要があるとされています。

[Service]
Type=forking
PIDFile=/var/run/myapp.pid

forking 型の場合、PIDFile に親プロセスの PID ファイルパスを指定する必要があります。

systemd の高度な機能

依存関係と起動順序

複数のサービスが相互依存する環境では、起動順序の管理が重要とされています。

After= — 指定されたサービスより後で起動（ただし依存しない）
Requires= — 依存サービスが起動しないと自分も起動しない
Wants= — 依存サービスの失敗を無視して起動

例えば Web アプリケーション（ポート 8080）が PostgreSQL（ポート 5432）に依存する場合：

[Unit]
Description=My Web App
Requires=postgresql.service
After=postgresql.service

この設定により、PostgreSQL が起動するまで Web アプリケーションは起動しません。

タイマーユニット

cron に代わるジョブスケジューラとして systemd.timer が利用されるとされています。例えば毎日午前 2 時にログをバックアップする場合：

[Unit]
Description=Daily backup

[Timer]
OnCalendar=daily
OnCalendar=*-*-* 02:00:00
Unit=backup.service

[Install]
WantedBy=timers.target

有効化は以下の通りです。

sudo systemctl enable --now backup.timer

セキュリティ考慮事項

Unit ファイルを作成する際は、以下のセキュリティ設定を検討するとされています。

User= / Group= — 最小権限の原則に従い、root ではなく専用ユーザーで実行
PrivateTmp=yes — /tmp と /var/tmp を隔離
NoNewPrivileges=yes — setuid バイナリの実行を制限
ProtectSystem=strict — /usr / /boot / /etc をリードオンリーに設定
ProtectHome=yes — ホームディレクトリへのアクセスを制限

セキュリティ設定の詳細については、公式ドキュメント（man systemd.service）で最新情報を確認することを強く推奨いたします。

まとめ

systemd はモダン Linux のサービス管理を標準化するシステムであり、以下のポイントが重要とされています。

基本操作 — start / stop / enable / disable / status の 5 つのコマンドで 90% のタスクに対応可能
Unit ファイル — [Unit] / [Service] / [Install] の 3 セクションで構成。daemon-reload を忘れずに
ログ管理 — journalctl でサービスのログを一元管理。スクリプト化による自動監視が容易
トラブル対応 — status と journalctl の組み合わせで大多数の問題を診断できる
高度な機能 — 依存関係管理・タイマー機能・セキュリティサンドボックス化が利用可能

「起動しない」「自動起動しない」といったトラブルは、systemd の動作原理を理解することで予防・解決できる可能性があります。本記事の内容を実際の運用環境で試し、トラブル時には man systemd.service（公式マニュアル）を合わせて参照することで、より堅牢なインフラ構築が実現できるとされています。