生産性を向上させるLinuxのsystemctlコマンド トップ5

Linuxシステムは、SSHアクセス、ネットワーキング、ログ記録、Webサーバー、データベース、スケジュールジョブ、デスクトップログイン画面など、ほぼすべてのバックグラウンドサービスに依存しています。これらのサービスのいずれかが正常に動作しなくなった場合、通常最初に使用するツールはsystemctlです。

systemctlは、多くの主流Linuxディストリビューションで使用されるサービス管理ツールsystemdの主要なコマンドラインインターフェースです。効果的に使用するためにすべてのサブコマンドを暗記する必要はありません。日常業務では、少数のコマンドでサービスの確認、再起動、起動設定の変更、ユニットファイルの更新のほとんどをカバーできます。

Systemdとsystemctlの理解

コマンドの詳細に入る前に、systemdとsystemctlについて簡単に復習しましょう。systemdはシステムの初期化、サービスの管理、プロセスの処理などを担当します。これはSysVinitやUpstartなどの古いinitシステムを置き換え、より高速な起動時間、並列サービス起動、より堅牢な依存関係管理を提供します。systemctlはsystemdの世界への窓口であり、サービス、ユニット、ターゲットの状態を制御および照会できます。

systemdの用語における「ユニット」とは、systemdが管理方法を知っているリソースを指します。サービス（.service）、マウントポイント（.mount）、デバイス（.device）、ソケット（.socket）、ターゲット（.target）が一般的なユニットタイプです。この記事では、主にsystemdによって管理されるデーモンプロセスを表すサービスユニットに焦点を当てます。

生産性向上のためのトップ5のsystemctlコマンド

Linuxシステムのサービスを管理および監視する能力を大幅に向上させる5つのsystemctlコマンドを紹介します。

1. systemctl status [SERVICE_NAME]

目的: このコマンドは、サービスの健全性とアクティビティを監視するための最初の防御線です。サービスが実行中か、最近停止したか、自動起動が有効か、さらには最新のログエントリなど、詳細な情報を提供します。

生産性が向上する理由: 問題を迅速に診断し、サービスの起動/シャットダウンを確認し、ログファイルを手動で調べることなくサービスの状態のスナップショットを取得できます。

例: Apache Webサーバーのステータスを確認するには（一部のディストリビューションではhttpd.service、Debian/Ubuntuなどではapache2.service）：

systemctl status apache2.service

出力の解釈（例）:

● apache2.service - The Apache HTTP Server
     Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2023-10-26 10:00:00 UTC; 1min 2s ago
       Docs: https://httpd.apache.org/docs/2.4/
    Process: 1234 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS)
   Main PID: 1239 (apache2)
      Tasks: 6 (limit: 4639)
     Memory: 21.6M
        CPU: 184ms
     CGroup: /system.slice/apache2.service
             ├─1239 /usr/sbin/apache2 -k start
             ├─1240 /usr/sbin/apache2 -k start
             └─1241 /usr/sbin/apache2 -k start

Oct 26 10:00:00 servername systemd[1]: Starting The Apache HTTP Server...
Oct 26 10:00:00 servername systemd[1]: Started The Apache HTTP Server.

この出力からわかること：

• Loaded: ユニットファイルの場所と、起動時に開始するように有効になっているかどうか。
• Active: 現在のステータス（例：active (running)、inactive (dead)、failed）。
• journalctlからの最近のログエントリ。

ヒント: qを押してステータスビューを終了します。

statusの2つの詳細は見落としがちです。まず、Loaded:はユニットファイルが存在するかどうか、および起動時に有効になっているかどうかを示します。サービスがactive (running)であってもdisabledである可能性があります。つまり、手動または別の依存関係によって開始されたが、次回の起動時に必ずしも開始されるとは限りません。次に、最後のログ行はプレビューにすぎません。有用なエラーがスクロールして見えなくなった場合は、statusですべてを詰め込もうとする代わりに、journalctl -u apache2.serviceを使用してください。

スクリプトや監視チェックでは、マシンフレンドリーなコマンドを優先します：

systemctl is-active --quiet apache2.service
systemctl is-enabled apache2.service

is-active --quietは、サービスがアクティブな場合に終了コード0で終了します。そのため、小さなヘルスチェックで役立ちます：

if ! systemctl is-active --quiet apache2.service; then
  echo "apache2 is not running"
fi

2. systemctl start|stop|restart [SERVICE_NAME]

目的: これらのコマンドは、サービスの実行時ライフサイクルを直接制御できます。

• start: サービスを開始します。
• stop: 実行中のサービスを停止します。
• restart: サービスを停止してから開始します（設定変更の適用に便利）。

生産性が向上する理由: 基本的なサービスメンテナンス、トラブルシューティング、設定更新の適用に不可欠です。システム全体を再起動する代わりに、個々のサービスを正確に制御できます。

例: Apache Webサーバーを停止するには：

sudo systemctl stop apache2.service

再度開始するには：

sudo systemctl start apache2.service

設定ファイルを変更した後に再起動するには：

sudo systemctl restart apache2.service

警告: これらのコマンドはシステム全体のサービスに影響を与えるため、通常はsudo権限が必要です。意図しない中断を避けるために、正しいサービスをターゲットにしていることを常に確認してください。

本番サービスではrestartを慎重に使用してください。プロセスを停止して再起動するため、アプリケーションが正常なシャットダウンを適切に処理しない限り、アクティブな接続が切断される可能性があります。ユニットがリロードをサポートしている場合、設定のみの変更後はこれがより適切です：

sudo systemctl reload nginx.service

すべてのサービスがリロードをサポートしているわけではありません。ユニット定義を確認してから想定してください：

systemctl cat nginx.service | grep ExecReload

ExecReload=がない場合、systemctl reloadは通常失敗します。その場合は、サービスを再起動するか、アプリケーション固有のリロードコマンドを使用します。

3. systemctl enable|disable [SERVICE_NAME]

目的: これらのコマンドは、システムの起動時にサービスが自動的に開始されるかどうかを管理します。

• enable: サービスが起動時に自動的に開始されるように設定します。これにより、適切なsystemdターゲットディレクトリからサービスのユニットファイルへのシンボリックリンクが作成されます。
• disable: シンボリックリンクを削除して、サービスが起動時に自動的に開始されるのを防ぎます。

生産性が向上する理由: リソース使用量を制御し、起動時間を最適化し、重要なサービスが常に利用可能であることを確認（または不要なサービスが実行されないようにする）できます。

例: Apacheがシステム起動時に毎回開始されるようにするには：

sudo systemctl enable apache2.service

不要なサービス（印刷を使用しない場合はcups.serviceなど）が起動時に開始されないようにするには：

sudo systemctl disable cups.service

ベストプラクティス: 不要なサービスは無効にしますが、最初にそれらに依存するものを確認してください。ラップトップでは、Bluetoothや印刷を無効にしても問題ない場合があります。サーバーでは、依存関係を確認せずにネットワーク、ストレージ、または認証サービスを無効にすると、ロックアウトされたり、起動が失敗したりする可能性があります。

enableとdisableは起動時の動作にのみ影響することに注意してください。現在のサービスを開始または停止するわけではありません。両方のアクションを一緒に実行する場合は、次を使用します：

sudo systemctl enable --now apache2.service
sudo systemctl disable --now cups.service

--nowは、サービスを有効にしてすでに実行されていると想定するという一般的な間違いを排除するため便利です。

4. systemctl list-unit-files --type=service

目的: このコマンドは、システムに認識されているすべてのsystemdサービスユニットファイルを、そのenabledまたはdisabledステータスとともに一覧表示します。これは、システム上で設定されているサービスの概要を把握するのに非常に便利です。

生産性が向上する理由: インストールされているサービスを発見し、不要なものを特定し、システムの起動設定を監査するのに役立ちます。システムの偵察とクリーンアップのための強力なツールです。

例:

systemctl list-unit-files --type=service

部分的な出力（例）:

UNIT FILE                                  STATE
acpid.service                              enabled
aptd-auto-update.service                   static
apt-daily.service                          static
apache2.service                            enabled
avahi-daemon.service                       enabled
bluetooth.service                          enabled
cups.service                               enabled
... (さらに多くのサービス)

78 unit files listed.

ヒント: STATE列は、サービスが起動時に開始するように設定されているか（enabled）、明示的に防止されているか（disabled）、またはstatic（systemctl enable/disableで直接有効/無効にできない、多くの場合依存関係または内部systemdユニット）を示します。

フィルタリング: 出力をgrepにパイプして特定のサービスを見つけることができます：

systemctl list-unit-files --type=service | grep ssh

インストールされているユニットファイルではなく、実行中のサービスに関心がある場合は、代わりにlist-unitsを使用します：

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

この区別はクリーンアップ時に重要です。list-unit-filesはsystemdが開始方法を知っているものを示します。list-unitsはsystemdが現在の実行時状態でロードしたものを示します。

5. systemctl daemon-reload

目的: systemdユニットファイルを変更した後（例：/etc/systemd/system/に新しいサービスファイルを作成したり、既存のものを編集したり）、systemdはこれらの変更を自動的に認識しません。systemctl daemon-reloadは、systemdにすべてのユニットファイルを再スキャンして設定をリロードするように指示します。

生産性が向上する理由: サービス設定の変更を適用するためだけにシステム全体を再起動する必要がなくなります。サービス設定を頻繁に変更する開発者や管理者にとって重要です。

例: カスタムアプリケーションmywebapp.service用の新しいサービスユニットファイルを作成したとします。

1. /etc/systemd/system/mywebapp.serviceを作成します。

2. systemdの設定をリロードします：

sudo systemctl daemon-reload ```

1. これで、systemdはmywebapp.serviceを認識し、start、enable、statusを実行できます：

sudo systemctl start mywebapp.service sudo systemctl enable mywebapp.service systemctl status mywebapp.service ```

重要: daemon-reloadはユニット定義のみをリロードします。サービスがすでに実行されている場合、ユニットファイルへの変更はサービスが再起動されるまで有効になりません（systemctl restart [SERVICE_NAME]）。

シンプルな日常ワークフロー

慣れていないサーバーにログインしたとき、私は通常次の順序で作業します：

systemctl status sshd.service
systemctl list-units --type=service --state=failed
systemctl list-unit-files --type=service | grep enabled
systemctl get-default

これにより、ホストの状態を迅速に把握できます：リモートアクセスが正常か、失敗したユニットはないか、起動時に開始するように設定されているものは何か、マシンがサーバースタイルかグラフィカルターゲットのどちらで起動することが期待されているか。

サービスの変更の場合、ワークフローも同様に短いです：

sudo systemctl edit myapp.service
sudo systemctl daemon-reload
sudo systemctl restart myapp.service
systemctl status myapp.service
journalctl -u myapp.service -n 50 --no-pager

このシーケンスにより、変更を可視化し、systemdのユニットキャッシュをリロードし、影響を受けるサービスのみを再起動し、その場を離れる前にログを確認できます。これにより、多くの回避可能な再起動と推測作業を防ぐことができます。

便利なバリエーション

コアコマンドに慣れてきたら、基本的なワークフローを変えずに時間を節約できるいくつかのバリエーションを追加します。

失敗したユニットのみを表示するには：

systemctl --failed

これは再起動後の最も迅速なチェックの1つです。パッケージのアップグレードでユニットが変更されたり、マウントがタイムアウトしたり、カスタムサービスが起動中にクラッシュした場合、ユーザーが問題を報告する前にここに表示されることがよくあります。

systemdがロードした正確なユニットコンテンツを検査するには：

systemctl cat docker.service

これは、編集したファイルが全体像ではない可能性があるため重要です。/usr/lib/systemd/system/のパッケージユニットは、/etc/systemd/system/docker.service.d/の下の1つ以上のドロップインによって変更される可能性があります。systemctl catは結合されたビューを表示するため、間違ったファイルをデバッグする必要がありません。

サービスが起動時に開始される理由を確認するには：

systemctl list-dependencies multi-user.target
systemctl list-dependencies graphical.target

これは、「なぜこれが実行されているのか？」と誰かが尋ねたときに役立ちます。サービスは直接有効にされているか、ターゲットによってプルされているか、ソケットアクティベートされているか、別のユニットによって開始されている可能性があります。起動動作は、多くの場合、有効か無効かの問題ではなく、依存関係の問題です。

ページャーを開かずに最近のログを確認するには：

journalctl -u sshd.service -n 50 --no-pager

systemctl statusは小さなログプレビューを提供しますが、journalctlは時間範囲、起動、行数、出力形式を制御できます。例：

journalctl -u sshd.service --since "today" --no-pager
journalctl -u sshd.service -b -1 --no-pager

2番目のコマンドは前回の起動をチェックするため、クラッシュや予期しない再起動の後に便利です。

最も長いsystemctlコマンドを使用しても賞品はありません。生産性は、現在の質問に答える小さなコマンドを知っていることから生まれます：実行中か、起動時に開始すべきか、何が失敗したか、何が変更されたか、systemdは編集した定義をリロードしたか。

共有マシンでの最後の習慣：変更した証拠を残すこと。サービスを無効にする場合は、チケット、ランブック、または変更ログに理由を記録してください。6か月後、誰かがdisabledを見て間違いだと思うかもしれません。コマンドは簡単です：

sudo systemctl disable --now old-worker.service

運用コンテキストは人々が失う部分です。タイマーに置き換えられましたか？重複ジョブを引き起こしていましたか？移行中にのみ必要でしたか？systemctlは状態を表示できますが、意図を説明することはできません。変更の横に短いメモを残すことで、次の人が良い決定を元に戻すのを防ぐことができます。