systemdでサービス管理
前提:5-1が完了し、tree・htopがインストール済みのホームディレクトリ(~)にいる状態から始めます。あなたが今こうしてSSHでサーバーにつなげているのも、裏側でsshというサービスが24時間動き続けているおかげです。Linuxではこうした「裏で動き続けるプログラム」をサービス※1と呼び、systemdという仕組みがまとめて管理しています。このページではsystemctlコマンドを使って、サービスの状態を見る・再起動する・自動起動の設定を確認する練習をします。
このページではSET 1〜3、合計30行のコマンドを上から順に叩きます。手打ち推奨(コピーは確認用)です。
SET 1 ― サービスの状態を見る
- $systemctl status ssh
- ● ssh.service - OpenBSD Secure Shell server
- Active: active (running) since ...
- $q
- $systemctl status cron
- ● cron.service - Regular background program processing daemon
- $q
- $systemctl is-active ssh
- $systemctl is-enabled ssh
- $systemctl is-enabled cron
- $systemctl list-units --type=service | head
- $systemctl list-units --type=service --state=running | wc -l
- $cd ~
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でその総数を数えています。
サービスは「お店の従業員」だとイメージしてください。statusは「今その人は出勤しているか」の確認、is-enabledは「そもそもシフトに入る契約になっているか」の確認です。出勤していても契約が切れていることもあれば、契約はあるのにまだ出勤前ということもあります。
あたし最初「サービスってなに?アプリと何が違うの?」ってなったんだけど、今回のsshで一気に腑に落ちたよ。自分が今つなげてるこのSSH接続自体が、裏で動いてるsshサービスのおかげなんだって考えると、急に身近に感じない?
SET 2 ― start/stop/enable/disableの違い
- $sudo systemctl restart cron
- $systemctl status cron
- Active: active (running) since ... (数秒前)
- $q
- $sudo systemctl stop cron
- $systemctl is-active cron
- inactive
- $systemctl status cron | grep Active
- $sudo systemctl start cron
- $systemctl is-active cron
- active
- $systemctl is-enabled cron
- $cd ~
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 | サーバー起動時の自動起動をやめる | 次回起動時から |
「動いているのに再起動したら消えた」「止めたはずなのに再起動したら動いていた」という事故は、たいていstart/stopとenable/disableを混同したときに起きます。両方セットで指定したいときはsudo systemctl enable --now cronのように--nowを付けると一度に済ませられます。
SET 3 ― 設定ファイルとの関係を知る
- $systemctl list-unit-files --type=service | head
- $systemctl list-unit-files --type=service | wc -l
- $systemctl list-unit-files --state=enabled | wc -l
- $systemctl status ssh.service | grep Loaded
- Loaded: loaded (/usr/lib/systemd/system/ssh.service; enabled)
- $systemctl status cron.service | grep Loaded
- $sudo systemctl daemon-reload
- $systemctl status ssh | grep Active
- $systemctl --failed
- $uptime
- $cd ~
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サービスを実際に動かし、「決まった時間に自動で処理を実行する」という管理者らしい仕事を体験します。