systemctl マスターガイド: Linux サービス管理のための必須コマンド

Linux サーバーを運用するなら、systemctl を常に使うことになります。Nginx が起動しないとき、再起動後に PostgreSQL を立ち上げる必要があるとき、デプロイでクリーンな再起動が必要なとき、そしてサービスが「失敗」と表示するものの実際のエラーがジャーナルに埋もれているときなどに使います。

このコマンドは難しくありませんが、いくつかの重要な違いを理解しておく必要があります。起動と有効化は同じではなく、リロードと再起動は同じではなく、無効化とマスクも同じではありません。これらが明確になれば、サービス管理はずっと簡単になります。

systemd と systemctl を理解する

systemd は、主要な Linux ディストリビューション（一般的な Debian、Ubuntu、Fedora、RHEL 系など）で使用される init システム兼サービス管理ツールです。ユーザースペースを初期化し、プロセス、セッション、タイマー、ソケット、マウント、サービスを管理します。

systemctl は、systemd マネージャーとそのコンポーネント（ユニット）の状態を制御・確認するための主要なコマンドラインユーティリティです。バックグラウンドで動作するプログラム（デーモン）であるサービスは、サービスユニット（通常 .service で終わる）として管理されます。

主要な概念: ユニットとターゲット

この記事ではサービスに焦点を当てますが、systemctl はさまざまなユニットを管理することを覚えておいてください。

サービスユニット (.service): バックグラウンドプロセスを管理するため（例: nginx.service）。
ターゲットユニット (.target): 特定のシステム状態を表すためにユニットをグループ化するため（例: 典型的なサーバー環境を表す multi-user.target）。

サービス制御のための必須コマンド（実行時状態）

これらのコマンドは、アクティブなシステムセッションにおいて、サービスが現在実行中か停止中かを直接制御します。

1. サービスの起動

start コマンドを使用すると、ブート時の設定に関係なく、サービスを即座に起動できます。

sudo systemctl start <サービス名>.service
# 例: Apache Web サーバーを起動
sudo systemctl start apache2.service

2. サービスの停止

stop コマンドを使用すると、実行中のサービスを正常に終了できます。

sudo systemctl stop <サービス名>.service
# 例: MySQL データベースサービスを停止
sudo systemctl stop mariadb.service

3. サービスの再起動

これは設定ファイルを変更した後によく使用されます。サービスを停止し、すぐに再起動します。

sudo systemctl restart <サービス名>.service
# 例: SSH デーモンを再起動
sudo systemctl restart sshd.service

4. 設定のリロード

多くのサービスはリロード操作をサポートしており、既存の接続を中断したりプロセスを完全に停止したりせずに、新しい設定ファイルを適用できます。完全な再起動よりも高速で、影響が少ない方法です。

sudo systemctl reload <サービス名>.service
# 例: Nginx 設定をリロード
sudo systemctl reload nginx.service

ヒント: 必ずサービスのドキュメントを確認してください。サービスが reload をサポートしていない場合は、設定変更後に restart を使用する必要があります。

サービス永続化のための必須コマンド（ブート状態）

サービスの起動は今実行することを意味しますが、有効化または無効化は、システム起動時に自動的に起動するかどうかを制御します。

1. サービスの有効化

再起動後にサービスが自動的に起動するようにするには、有効化する必要があります。これにより、systemd 設定ディレクトリ（/etc/systemd/system/）に必要なシンボリックリンクが作成されます。

sudo systemctl enable <サービス名>.service
# 例: PostgreSQL を起動時に有効化
sudo systemctl enable postgresql.service

2. サービスの無効化

サービスが起動時に自動的に起動しないようにするには、無効化する必要があります。これにより、enable コマンドで作成されたシンボリックリンクが削除されます。

sudo systemctl disable <サービス名>.service
# 例: サーバー上の Bluetooth サービスを無効化
sudo systemctl disable bluetooth.service

3. サービスのマスク

ユニットをマスクすると、手動、自動、または依存関係による起動を防ぐことができます。「これを起動しない」という制限を disable よりも強固にしたい場合に使用します。

sudo systemctl mask <サービス名>.service

# マスクを解除するには:
sudo systemctl unmask <サービス名>.service

サービスの状態と情報の確認

サービスが実行中かどうか、そしてなぜ失敗している可能性があるかを知ることは、トラブルシューティングにとって重要です。

1. 状態の確認

status コマンドは、サービスの詳細なスナップショットを即座に提供します。アクティブかどうか、ロードされているか、プロセス ID、最近のログエントリなどが表示されます。

systemctl status <サービス名>.service
# 例: ファイアウォールの状態を確認
systemctl status firewalld.service

出力の解釈:

出力内の次の 3 つの主要な行を確認してください。

Loaded: ユニットファイルが正しくロードされたかどうかを示します（例: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)）。
Active: 現在の実行時状態を示します（例: active (running) または failed）。
CGroup: サービスに関連するプロセスツリーを示します。

2. ブート永続性の確認

完全なステータス出力を確認しなくても、サービスが自動起動するように設定されているかどうかを確認できます。

systemctl is-enabled <サービス名>.service
# 出力は 'enabled'、'disabled'、または 'masked' になります

3. journalctl でログを表示する

status は出力の最後の数行を表示しますが、詳細なデバッグには journalctl を使用する必要があります。このコマンドは、すべてのシステムログとサービスログを収集する systemd ジャーナルを照会します。

特定のサービスのログを表示するには:

# 最後の再起動以降のサービスのすべてのログを表示
journalctl -u <サービス名>.service

# リアルタイムでログを表示（tail -f と同様）
journalctl -u <サービス名>.service -f

# 昨日以降のログを表示
journalctl -u <サービス名>.service --since "yesterday"

警告: サービスが failed ステータスを示している場合、journalctl -u <サービス> -r（逆順、新しいものから表示）が、失敗の原因となったエラーメッセージを確認する最も速い方法です。

4. スクリプト内でサービスが実行中かどうかを確認する

シェルスクリプトでは、systemctl status は冗長すぎます。クエリコマンドを使用してください。

systemctl is-active --quiet nginx.service
echo $?

systemctl is-failed nginx.service
systemctl is-enabled nginx.service

is-active --quiet は、完全なステータスページを表示せずに、有用な終了ステータスを返します。そのため、ヘルスチェックや自動化に適しています。

if ! systemctl is-active --quiet nginx.service; then
    echo "nginx が実行されていません" >&2
    exit 1
fi

5. ユニットの一覧表示

正確なサービス名がわからない場合は、ユニットを一覧表示します。

systemctl list-units --type=service
systemctl list-units --type=service --state=failed
systemctl list-unit-files --type=service

list-units はロードされたユニットとその現在の実行時状態を表示します。list-unit-files はユニットファイルと、それらが有効、無効、静的、マスク、または生成済みかどうかを表示します。この違いにより、サービスがディスク上に存在してもアクティブなユニットリストに表示されない理由が説明されます。

システム状態の管理（ターゲット）

systemctl は、主にターゲットを介して、グローバルなシステム状態を管理するためにも使用されます。

1. 現在のシステム状態の表示

システムが現在どのターゲットで起動しているかを確認するには（例: サーバー環境かグラフィカルデスクトップか）:

systemctl get-default

2. デフォルトのブートターゲットの変更

GUI を起動してはならないサーバーを設定している場合、デフォルトのターゲットを multi-user.target に設定できます。

sudo systemctl set-default multi-user.target

3. 再起動とシャットダウン

reboot や shutdown コマンドも引き続き機能しますが、systemctl はこれらのアクションを実行するネイティブな方法を提供します。

# システムを即座に再起動
sudo systemctl reboot

# システムを停止（電源オフ）
sudo systemctl poweroff

ユニット変更後の systemd のリロード

ユニットファイルを編集したり、/etc/systemd/system 以下にドロップインを追加したりしても、systemd は自動的に再読み込みしません。次のコマンドを実行してください。

sudo systemctl daemon-reload

その後、影響を受けるサービスを再起動またはリロードします。

sudo systemctl restart myapp.service

ベンダーファイルとドロップインがマージされた後の最終的なユニットを確認するには:

systemctl cat myapp.service
systemctl show myapp.service -p FragmentPath -p DropInPaths

これは「間違ったファイルを編集した」問題を発見する最も速い方法の 1 つです。

実際のトラブルシューティングフロー

サービスが起動に失敗した場合、次の順序で作業を進めてください。

状態を確認:

systemctl status myapp.service

そのユニットのログを読む:

journalctl -u myapp.service -r

最近サービスファイルを編集した場合は、systemd をリロード:

sudo systemctl daemon-reload

サービスを再起動し、ログをリアルタイムで追跡:

sudo systemctl restart myapp.service
journalctl -u myapp.service -f

すぐに失敗する場合は、ユニット定義を確認:

systemctl cat myapp.service
systemctl show myapp.service -p ExecStart -p User -p WorkingDirectory

ほとんどの失敗はごく普通のものです。ExecStart のパスが間違っている、環境ファイルがない、権限の問題、ワーキングディレクトリが不正、ポートが既に使用されている、アプリケーション自体の設定構文エラーなどです。

起動、有効化、再起動、リロード: メンタルモデル

これら 4 つの動詞は混同しやすいです。

start は現在の実行時状態を変更します。
enable はブート動作を変更します。
restart はプロセスを停止して起動します。
reload は、サービスがサポートしている場合、既存のプロセスに設定の再読み込みを要求します。

たとえば、Nginx をインストールした後:

sudo systemctl start nginx.service
sudo systemctl enable nginx.service

最初のコマンドは今すぐ起動します。2 番目のコマンドは、再起動後に起動するようにします。start のみを実行した場合、サービスは次の再起動後に消える可能性があります。enable のみを実行した場合、ユニットに特別なインストール動作がない限り、次の再起動まで実行されない可能性があります。

Nginx 設定を編集した後は、最初にアプリケーション設定をテストしてからリロードします。

sudo nginx -t
sudo systemctl reload nginx.service

アプリケーションがリロードをサポートしていない場合は、再起動を使用し、中断を計画してください。

sudo systemctl restart myapp.service

マスクのより安全な使用法

マスクは便利ですが、次にサービスを起動しようとする人を混乱させる可能性があります。

sudo systemctl mask bluetooth.service
systemctl is-enabled bluetooth.service

サービスは masked と報告します。元に戻すには:

sudo systemctl unmask bluetooth.service

明確な競合がある場合、たとえば古いサービスを新しいものに置き換えた後に起動されないようにする場合などにマスクを使用してください。通常の「起動時に起動しない」動作には、disable を使用してください。

保守可能な方法でのユニットの編集

パッケージ化されたサービスを変更する必要がある場合は、/usr/lib/systemd/system や /lib/systemd/system 以下のファイルを直接編集しないでください。パッケージのアップグレードによってこれらのファイルが置き換えられる可能性があります。オーバーライドを使用してください。

sudo systemctl edit myapp.service

これにより、/etc/systemd/system/myapp.service.d/ 以下にドロップインが作成されます。例:

[Service]
Environment=APP_ENV=production
Restart=on-failure
RestartSec=5s

次に、それを適用します:

sudo systemctl daemon-reload
sudo systemctl restart myapp.service

後でオーバーライドを削除する必要がある場合は、最初にドロップインを確認します:

systemctl show myapp.service -p DropInPaths

次に、特定のドロップインファイルを削除し、daemon-reload を実行します。これにより、ローカルの変更が可視化され、監査が容易になります。

ユーザーサービス

すべてのサービスがシステムサービスであるとは限りません。デスクトップツール、開発デーモン、ユーザーごとのバックグラウンドプロセスは、ユーザーマネージャーの下で実行される場合があります。

systemctl --user status pipewire.service
systemctl --user restart my-user-job.service

ユーザーサービスは同じ方法で sudo を使用せず、ユーザーの systemd インスタンスの下に存在します。コマンドが systemctl --user では機能するが、通常の systemctl では機能しない場合、それはシステムユニットではなく、ユーザーユニットを参照しています。

サーバー上の長時間実行されるユーザーサービスの場合、ログイン/セッションの動作が重要になることがあります。一部のディストリビューションでは、ログアウト後もユーザーのサービスを実行し続けるために、linger を有効にする必要があります。

loginctl enable-linger deploy

これは意図的に使用してください。ユーザーサービスは、開発やユーザースコープの自動化に適したツールですが、本番環境のデーモンは、多くの場合、明示的なユーザーと権限を持つシステムサービスとしての方が明確です。

主要な systemctl コマンドのまとめ

アクション	コマンド構文	目的
今すぐ起動	`sudo systemctl start 名前.service`	サービスを即座に実行します。
今すぐ停止	`sudo systemctl stop 名前.service`	実行中のサービスを終了します。
再起動	`sudo systemctl restart 名前.service`	サービスを停止してから起動します。
リロード	`sudo systemctl reload 名前.service`	完全な再起動なしで設定変更を適用します（サポートされている場合）。
有効化	`sudo systemctl enable 名前.service`	起動時にサービスが開始されるように設定します。
無効化	`sudo systemctl disable 名前.service`	起動時にサービスが開始されないようにします。
状態確認	`systemctl status 名前.service`	実行時状態と最近のログを確認します。
ログ表示	`journalctl -u 名前.service`	サービスの完全な systemd ジャーナル履歴にアクセスします。

これらのコマンドで、日常的なサービスの作業のほとんどをカバーできます。start と stop は現在のプロセスを制御します。enable と disable はブート動作を制御します。status、is-active、journalctl は何が起こったかを教えてくれます。daemon-reload は systemd をユニットファイルの編集と同期させます。これらの役割を区別して覚えておけば、systemctl は古いメモからコピーするコマンドではなく、実用的なトラブルシューティングツールになります。