systemdとは？Linuxのサービス管理を基礎から解説｜systemctl完全ガイド

Linuxサーバーを運用する上で、「Webサーバーを起動する」「データベースを再起動する」「サービスの自動起動を設定する」といった操作は日常的に行います。これらのサービス管理を担うのが「systemd」です。

systemdは、現在のほぼすべての主要Linuxディストリビューションで採用されている初期化システム（initシステム）であり、サーバーの起動からサービスの管理、ログの収集まで幅広い機能を提供します。

本記事では、systemdの基本概念からsystemctlコマンドの実践的な使い方、独自サービスの作成方法まで体系的に解説します。Linuxの基礎と基本コマンドを理解していることを前提としています。

systemdとは？Linuxの起動とサービス管理の中核

systemdは、Linux起動時に最初に実行されるプロセス（PID 1）であり、システム全体のプロセス管理を統括するシステムです。2010年にLennart Poettering氏とKay Sievers氏によって開発が始まり、現在ではUbuntu、Rocky Linux、AlmaLinux、Debian、Fedoraなど、ほぼすべての主要ディストリビューションで標準採用されています。

systemdが管理するもの

systemdは単なるサービス管理ツールではなく、以下の機能を包括的に提供します。

サービス（デーモン）管理：Webサーバー、データベース、SSHサーバーなどの起動・停止・再起動を管理します。

システム起動プロセス：PCの電源が入ってからログイン画面が表示されるまでの起動シーケンスを制御します。

ログ管理（journald）：システム全体のログを一元管理します。詳しくはLinuxのログ管理ガイドで解説しています。

タイマー機能：cronの代替となるタスクスケジューリング機能を提供します。

マウント管理：ファイルシステムのマウントを管理します。

ネットワーク管理：ネットワークインターフェースの設定と管理を行います。

「ユニット」という概念

systemdが管理するすべてのリソースは「ユニット（Unit）」と呼ばれます。ユニットには複数の種類があり、ファイルの拡張子で区別されます。

.service：サービス（デーモン）を定義。最も頻繁に扱うユニットタイプです。
.timer：タイマー（定期実行タスク）を定義。
.socket：ソケットベースのアクティベーションを定義。
.target：複数のユニットをグループ化する論理的な単位。
.mount：ファイルシステムのマウントポイントを定義。
.path：ファイルやディレクトリの監視を定義。

サーバー管理の日常業務では、主に .service ユニットを操作することになります。

systemctlの基本操作｜サービスの起動・停止・確認

systemdを操作するためのコマンドが systemctl です。サーバー管理者が最も頻繁に使うコマンドの一つであり、その基本操作を確実に覚えましょう。

サービスの状態確認

特定のサービスの現在の状態を確認するには、以下のコマンドを使用します。

systemctl status nginx

このコマンドは、サービスの稼働状態、プロセスID、メモリ使用量、最近のログなど、サービスに関する包括的な情報を表示します。出力の主な項目を説明します。

Active：active (running) は正常稼働中、inactive (dead) は停止中、failed は異常停止を示します。
Main PID：サービスのメインプロセスのIDです。プロセス管理の知識があるとトラブルシューティングに役立ちます。
CGroup：サービスが属するコントロールグループと、その配下のプロセスが表示されます。
ログ出力：最新のログメッセージが数行表示されます。

サービスの起動・停止・再起動

サービスの起動：

sudo systemctl start nginx

サービスの停止：

sudo systemctl stop nginx

サービスの再起動：

sudo systemctl restart nginx

設定のリロード（プロセスを停止せずに設定を再読み込み）：

sudo systemctl reload nginx

reload は、設定変更を反映する際にダウンタイムなしで行えるため、本番環境では restart よりも優先して使うべきです。ただし、すべてのサービスが reload に対応しているわけではありません。

条件付きリスタート（稼働中の場合のみ再起動）：

sudo systemctl try-restart nginx

サービスの自動起動設定

サーバーの再起動後にサービスが自動的に起動するよう設定するのが enable コマンドです。

自動起動を有効にする：

sudo systemctl enable nginx

自動起動を無効にする：

sudo systemctl disable nginx

自動起動の有効化と同時にサービスを起動する：

sudo systemctl enable --now nginx

enable はあくまで「次回起動時の自動起動設定」であり、今すぐサービスを起動する場合は start も合わせて実行する必要があります。--now オプションを使えば両方を一度に行えます。

自動起動設定の確認

systemctl is-enabled nginx

enabled と表示されれば自動起動が有効、disabled と表示されれば無効です。

サービス一覧の確認と管理

サーバー上で動作しているサービスの全体像を把握することは、運用管理の基本です。

稼働中のサービス一覧

systemctl list-units --type=service

このコマンドはロードされたサービスユニットの一覧を表示します。--state=running を追加すると、現在稼働中のサービスのみに絞り込めます。

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

自動起動が設定されたサービス一覧

systemctl list-unit-files --type=service

各サービスの自動起動設定（enabled / disabled / static / masked）を確認できます。

static：他のサービスから依存関係で起動されるが、単独での自動起動設定は行えないサービス。
masked：手動でも自動でも起動できないように完全に無効化されたサービス。

不要なサービスの無効化

セキュリティとパフォーマンスの観点から、不要なサービスは無効化しておくべきです。

sudo systemctl disable --now bluetooth.service

サーバー環境では、Bluetooth、プリンター関連、デスクトップ環境関連などのサービスは通常不要です。ただし、依存関係のあるサービスを安易に停止すると問題が発生する可能性があるため、事前に依存関係を確認してください。

systemctl list-dependencies nginx.service

このコマンドで、指定したサービスが依存する他のサービスをツリー形式で確認できます。

ユニットファイルの構造と読み方

systemdのサービスがどのように定義されているかを理解することで、トラブルシューティングやカスタマイズが容易になります。

ユニットファイルの配置場所

ユニットファイルは主に2つの場所に配置されています。

/usr/lib/systemd/system/：パッケージマネージャーによってインストールされたデフォルトのユニットファイル。直接編集しないでください。

/etc/systemd/system/：管理者がカスタマイズまたは新規作成するユニットファイル。こちらが優先されます。

既存のサービスの設定を変更したい場合は、元のファイルを直接編集するのではなく、systemctl edit コマンドを使用します。

sudo systemctl edit nginx.service

これにより、オーバーライド用の設定ファイルが自動的に作成され、元の設定を安全にカスタマイズできます。

ユニットファイルの構成

典型的なサービスのユニットファイルは、3つのセクションで構成されています。

[Unit]セクション：サービスの説明と依存関係を定義します。

Description= にはサービスの説明を記述します。After= には、このサービスの前に起動しておくべきユニットを指定します。例えば、Webサーバーであれば After=network.target と記述して、ネットワークが利用可能になった後に起動するようにします。

[Service]セクション：サービスの動作を定義する中核部分です。

Type= にはサービスの種類を指定します。主なタイプは以下の通りです。
simple：ExecStartで指定したプロセスがメインプロセスとなる（デフォルト）。
forking：メインプロセスがフォークして子プロセスを起動するデーモン向け。
oneshot：起動時に一度だけ実行して終了するタスク向け。

ExecStart= にはサービスの起動コマンドを指定します。
ExecReload= には設定リロード時のコマンドを指定します。
Restart= にはサービスの自動再起動ポリシーを指定します。always、on-failure、on-abnormal などの値を設定できます。

[Install]セクション：自動起動の設定を定義します。

WantedBy=multi-user.target と記述すると、通常のマルチユーザーモードで自動起動されるようになります。

独自サービスの作成｜自社アプリケーションをsystemdで管理する

自社で開発したアプリケーションやスクリプトをsystemdのサービスとして管理する方法を解説します。これにより、自動起動、ログ管理、異常時の自動再起動といったsystemdの恩恵を受けられます。

バックアップスクリプトのサービス化

例として、毎日実行するバックアップスクリプトをsystemdのサービスとタイマーで管理する方法を示します。

まず、バックアップスクリプト（/usr/local/bin/backup.sh）が既に作成されていると仮定します。シェルスクリプトの書き方はシェルスクリプト入門を参照してください。

サービスユニットファイルを作成します。Vimエディタで以下の内容を記述します。

sudo vim /etc/systemd/system/backup.service

[Unit]セクションに Description=Daily Backup Service と記述し、[Service]セクションに Type=oneshot、ExecStart=/usr/local/bin/backup.sh と記述します。ファイルのパーミッション設定についてはパーミッションガイドを確認してください。

タイマーユニットの作成

cronの代わりにsystemdのタイマーを使って定期実行を設定します。

sudo vim /etc/systemd/system/backup.timer

[Unit]セクションに Description=Run Backup Daily、[Timer]セクションに OnCalendar=*-*-* 03:00:00（毎日午前3時に実行）、Persistent=true（前回の実行をスキップした場合に即実行）を設定し、[Install]セクションに WantedBy=timers.target を記述します。

タイマーを有効にします。

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer

cronとsystemdタイマーの使い分けについてはcronスケジューリングガイドで詳しく解説しています。

Webアプリケーションのサービス化

Node.jsやPythonで開発したWebアプリケーションをsystemdで管理する場合の例を紹介します。

sudo vim /etc/systemd/system/myapp.service

[Unit]セクションで Description=My Web Application、After=network.target を指定します。[Service]セクションでは Type=simple、User=www-data（実行ユーザー）、WorkingDirectory=/opt/myapp（作業ディレクトリ）、ExecStart=/usr/bin/node /opt/myapp/server.js（起動コマンド）を指定します。

また、Restart=on-failure と RestartSec=5 を設定することで、アプリケーションが異常終了した場合に5秒後に自動的に再起動されます。

環境変数を設定する必要がある場合は、Environment=NODE_ENV=production のようにユニットファイル内で直接指定するか、EnvironmentFile=/opt/myapp/.env のように外部ファイルから読み込む方法があります。

設定後、デーモンのリロードとサービスの有効化を行います。

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

トラブルシューティング｜サービスが起動しない場合の対処法

サービスが期待通りに動作しない場合の調査手順を解説します。

ステップ1：サービスの状態確認

systemctl status サービス名

出力の Active 行で状態を確認します。failed と表示されている場合は、下部に表示されるログメッセージから原因の手がかりを探します。

ステップ2：ログの詳細確認

journalctl -u サービス名 -n 50 --no-pager

指定したサービスの最新50行のログを表示します。-f オプションを付けるとリアルタイムでログを監視できます。

journalctl -u サービス名 -f

ログの見方に慣れることは、サーバー管理者にとって非常に重要です。ログ管理ガイドで基礎知識を身につけてください。

ステップ3：ユニットファイルの構文チェック

systemd-analyze verify /etc/systemd/system/myapp.service

ユニットファイルに構文エラーがないか検証します。問題がある場合はエラーメッセージが表示されます。

ステップ4：依存関係の確認

systemctl list-dependencies サービス名

依存するサービスの中に起動していないものがないか確認します。

よくある問題と解決策

「ExecStart= でコマンドが見つからない」：フルパスでコマンドを指定しているか確認してください。systemdはPATH環境変数を参照しないため、/usr/bin/node のようにフルパスで記述する必要があります。

「権限がない」エラー：実行ユーザー（User=）に適切な権限があるか、対象ファイルのパーミッションが正しいか確認してください。ファイルパーミッションガイドが参考になります。

「ポートが既に使用中」：別のプロセスが同じポートを使用している可能性があります。ss -tlnp コマンドで使用中のポートを確認してください。ネットワークコマンドの知識が役立ちます。

daemon-reloadの忘れ：ユニットファイルを変更した後は、必ず sudo systemctl daemon-reload を実行してください。これを忘れると変更が反映されません。

まとめ｜systemdはLinuxサーバー管理の基礎スキル

systemdとsystemctlの操作は、Linuxサーバーを管理する上で避けて通れない基本スキルです。本記事で解説した内容を実践すれば、日常のサービス管理から独自アプリケーションのデーモン化まで対応できるようになります。

本記事のポイントを整理します。

日常運用で必須のコマンド

• systemctl status：サービスの状態確認
• systemctl start / stop / restart：サービスの起動・停止・再起動
• systemctl enable / disable：自動起動の設定
• journalctl -u：サービス固有のログ確認

カスタマイズ・応用

• ユニットファイルの構造（[Unit]、[Service]、[Install]）の理解
• 独自サービスの作成とタイマーによる定期実行
• Restart=on-failure による自動復旧の設定

systemdの知識は、Ubuntu Serverの初期設定、Nginxのセットアップ、Dockerの運用など、あらゆるサーバー管理場面で活かされます。

サーバーのセキュリティ強化に取り組む際はセキュリティ強化ガイドを、パフォーマンスの最適化についてはパフォーマンス監視ガイドを、クラウド環境での運用はクラウドサーバー（AWS）ガイドをそれぞれ参照してください。systemdを使いこなすことで、Linuxサーバーの運用品質は確実に向上します。