第5章 5-2 / 管理者の仕事

systemdでサービス管理

このページで叩くコマンドと到達点

前提:5-1が完了し、tree・htopがインストール済みのホームディレクトリ(~)にいる状態から始めます。あなたが今こうしてSSHでサーバーにつなげているのも、裏側でsshというサービスが24時間動き続けているおかげです。Linuxではこうした「裏で動き続けるプログラム」をサービス※1と呼び、systemdという仕組みがまとめて管理しています。このページではsystemctlコマンドを使って、サービスの状態を見る・再起動する・自動起動の設定を確認する練習をします。

このページではSET 1〜3、合計30行のコマンドを上から順に叩きます。手打ち推奨(コピーは確認用)です。

SET 1 ― サービスの状態を見る

ubuntu@lightsail: ~
  1. $systemctl status ssh
  2. ● ssh.service - OpenBSD Secure Shell server
  3. Active: active (running) since ...
  4. $q
  5. $systemctl status cron
  6. ● cron.service - Regular background program processing daemon
  7. $q
  8. $systemctl is-active ssh
  9. $systemctl is-enabled ssh
  10. $systemctl is-enabled cron
  11. $systemctl list-units --type=service | head
  12. $systemctl list-units --type=service --state=running | wc -l
  13. $cd ~
解説 ― SET 1 で何をしたか

systemdはUbuntuのシステムが起動した瞬間から動き出す、あらゆるサービスの管理者です。その司令塔を操作するコマンドがsystemctl(system controlの略)です。1行目のsystemctl status sshで、あなたが今まさに接続に使っているSSHサービスの状態を確認します。出力例のActive: active (running)という行が、サービスが今まさに動いている証拠です。この画面はページャー※2で表示されるので、確認できたら2行目のqキーで抜けてください。

3行目のsystemctl status cronでは、5-3で本格的に扱う定期実行の番人cronサービスの状態を同じように確認します。こちらも4行目のqで抜けます。5行目のis-activeは状態の詳細を省き、activeかinactiveかの一言だけを返すので、スクリプトなどで機械的にチェックしたいときに便利です。

6〜7行目のsystemctl is-enabledは、statusとは似て非なる質問です。「今動いているか」ではなく「サーバー起動時に自動で立ち上がる設定になっているか」を確認します。SSHサーバーであるLightsailインスタンスでは当然enabledになっているはずです。このactive/inactive(今の状態)とenabled/disabled(自動起動設定)は別軸の情報だという点を、次のSET 2でさらに整理します。

8行目のsystemctl list-units --type=service | headで、今このサーバーで管理されているサービスの一覧を確認します。ネットワーク、ログ、時刻同期など、普段は意識しない多くのサービスが裏で動いていることがわかります。9行目では--state=runningで稼働中のものだけに絞り、wc -lでその総数を数えています。

POINT

サービスは「お店の従業員」だとイメージしてください。statusは「今その人は出勤しているか」の確認、is-enabledは「そもそもシフトに入る契約になっているか」の確認です。出勤していても契約が切れていることもあれば、契約はあるのにまだ出勤前ということもあります。

ゆみちゃん
ゆみ

あたし最初「サービスってなに?アプリと何が違うの?」ってなったんだけど、今回のsshで一気に腑に落ちたよ。自分が今つなげてるこのSSH接続自体が、裏で動いてるsshサービスのおかげなんだって考えると、急に身近に感じない?

SET 2 ― start/stop/enable/disableの違い

ubuntu@lightsail: ~
  1. $sudo systemctl restart cron
  2. $systemctl status cron
  3. Active: active (running) since ... (数秒前)
  4. $q
  5. $sudo systemctl stop cron
  6. $systemctl is-active cron
  7. inactive
  8. $systemctl status cron | grep Active
  9. $sudo systemctl start cron
  10. $systemctl is-active cron
  11. active
  12. $systemctl is-enabled cron
  13. $cd ~
解説 ― SET 2 で何をしたか

1行目のsudo systemctl restart cronは、cronサービスを一度止めてすぐに立ち上げ直すコマンドです。設定ファイルを書き換えたあとサービスに反映させたいときによく使います。systemctlでサービスの状態を変更する操作にはすべてsudoが必要です。これはサービスがシステム全体に影響する裏方の仕組みであり、一般ユーザーが自由に止められては困るためです。2行目で確認すると、出力例のように起動時刻が数秒前に更新されています。確認できたら3行目のqでページャーを抜けます。

4行目のsudo systemctl stop cronでサービスを完全に停止し、5行目でinactiveになったことを確認します。6行目のようにstatusとgrepを組み合わせれば、ページャーを開かずにピンポイントで状態行だけを確認することもできます。7行目のsudo systemctl start cronで再び起動し、8行目でactiveに戻ったことを確認します。start/stopは「今すぐ動かす/止める」というその場限りの操作である点が、次に説明するenable/disableとの一番の違いです。

9行目のsystemctl is-enabled cronを確認すると、通常はenabledになっています。仮にここでsudo systemctl stop cronだけを実行しても、サーバーを再起動すればcronはまた自動で立ち上がります。逆にsudo systemctl disable cronを実行すると(このドリルでは実行しません)、次回の再起動時からは自動で立ち上がらなくなりますが、disableした直後もサービス自体は動き続けたままです。つまりstart/stopは「今」、enable/disableは「次回起動時から先」という、時間軸の異なる設定だと理解してください。

コマンド効果いつ有効か
systemctl startサービスを今すぐ起動する今この瞬間
systemctl stopサービスを今すぐ停止する今この瞬間
systemctl enableサーバー起動時に自動で立ち上げる設定にする次回起動時から
systemctl disableサーバー起動時の自動起動をやめる次回起動時から
POINT

「動いているのに再起動したら消えた」「止めたはずなのに再起動したら動いていた」という事故は、たいていstart/stopとenable/disableを混同したときに起きます。両方セットで指定したいときはsudo systemctl enable --now cronのように--nowを付けると一度に済ませられます。

SET 3 ― 設定ファイルとの関係を知る

ubuntu@lightsail: ~
  1. $systemctl list-unit-files --type=service | head
  2. $systemctl list-unit-files --type=service | wc -l
  3. $systemctl list-unit-files --state=enabled | wc -l
  4. $systemctl status ssh.service | grep Loaded
  5. Loaded: loaded (/usr/lib/systemd/system/ssh.service; enabled)
  6. $systemctl status cron.service | grep Loaded
  7. $sudo systemctl daemon-reload
  8. $systemctl status ssh | grep Active
  9. $systemctl --failed
  10. $uptime
  11. $cd ~
解説 ― SET 3 で何をしたか

1行目のsystemctl list-unit-files --type=serviceは、SET 1のlist-unitsとよく似ていますが、こちらは「今動いているか」に関係なく、システムに登録されているサービス定義ファイル(unitファイル※3)すべてを一覧します。2行目のwc -lでその総数を確認し、3行目でenabled状態のものだけに絞って件数を数えています。

4行目のsystemctl status ssh.service | grep Loadedで、出力例のようにLoaded行を見ると/usr/lib/systemd/system/ssh.serviceという実際の設定ファイルの場所がわかります。サービスの正体は、この場所に置かれたテキストファイル(起動コマンドや依存関係が書かれた設定)なのです。5行目で同じようにcronの設定ファイルの場所も確認できます。

6行目のsudo systemctl daemon-reloadは、こうしたunitファイルを手動で書き換えたときに、systemd自身に「設定が変わったので読み直して」と伝えるコマンドです。このドリルでは設定ファイルを実際には書き換えませんが、7-1でサービスを自作する際にこのコマンドが必要になるので、存在だけ覚えておいてください。7行目で改めてsshの状態を確認し、変化がないことを見ておきます。

8行目のsystemctl --failedは、起動に失敗しているサービスだけを一覧するコマンドです。何も表示されなければ「失敗しているサービスはゼロ」という健全な状態です。サーバーの調子が悪いときに真っ先に叩くと当たりが早い、実務でも頻出のコマンドです。最後に9行目のuptime(4-2で登場済み)でサーバーが安定して稼働し続けていることを確認し、このページを締めくくります。

ゆみちゃん
ゆみ

systemctl --failed、あたしは「サーバーの体調チェック」って呼んでるよ。なんか調子悪いなってときにまずこれ叩くと、どのサービスが原因かすぐ絞り込めるから覚えておいて損はないよ!

まとめ

5-2では、systemctlを使ってサービスの状態確認・再起動・自動起動設定の確認方法を体験しました。このページで叩けるようになったコマンドを一覧にまとめます。

コマンド何をするか覚え方
systemctl status <名前>サービスの現在の状態を表示する従業員の出勤確認
systemctl is-active <名前>動いているかどうかだけを返す今動いてる?
systemctl is-enabled <名前>自動起動が設定されているか返すシフト契約あり?
sudo systemctl start <名前>サービスを今すぐ起動する今すぐ出勤
sudo systemctl stop <名前>サービスを今すぐ停止する今すぐ退勤
sudo systemctl restart <名前>サービスを再起動する一度帰って出勤し直す
systemctl list-units --type=service稼働中心にサービス一覧を見る今動いてる従業員一覧
systemctl list-unit-files登録済みの全サービス定義を見る雇用契約の台帳
systemctl --failed起動失敗しているサービスを一覧するサーバーの体調チェック

次のページ「5-3. cronで定期実行」では、今日status確認だけしたcronサービスを実際に動かし、「決まった時間に自動で処理を実行する」という管理者らしい仕事を体験します。

脚注 ─ 用語解説
  1. サービス … ユーザーの操作なしに裏側で動き続けるプログラム。SSHサーバーやWebサーバー、時刻同期などが代表例。デーモン(daemon)とも呼ばれる。↩
  2. ページャー … 長い出力を1画面ずつ表示するプログラム。1-4で学んだlessと同じ仕組みで、qで終了する。↩
  3. unitファイル … systemdがサービスをどう起動・管理するかを記述した設定ファイル。/usr/lib/systemd/system/などに置かれている。↩