はじめに
この実験では、systemctl コマンドを使用して RHEL 上のシステムサービスを管理する実践的な経験を積みます。ロード済みおよびアクティブなすべてのサービスを表示する方法、特定のサービスのステータスを確認する方法、起動・停止・再起動によって実行時の動作を制御する方法を学びます。さらに、サービス設定の再読み込み、起動時の自動開始を有効または無効にする方法、そしてサービスの起動を完全に防ぐためのマスキング（masking）とアンマスキング（unmasking）という高度な概念についても理解を深めます。
この実践ガイドを通じて、RHEL システムの運用に不可欠なサービスのライフサイクルを監視・管理するための重要なスキルを習得します。
systemctl を使用したロード済みおよびアクティブなサービスの表示
このステップでは、systemctl コマンドを使用して、自動的に開始されるシステムプロセスを特定する方法を学びます。systemctl は、Red Hat Enterprise Linux において systemd サービスを管理するための主要なツールです。
まず、現在ロードされ、アクティブになっているすべてのサービスユニットを一覧表示する方法を確認します。これには systemctl list-units --type=service コマンドを使用します。このコマンドは、systemd デーモンが正常に解析してメモリにロードし、現在アクティブな状態にあるサービスユニットを表示します。
RHEL 環境でターミナルを開いてください。すでに labex ユーザーとしてログインしており、現在のディレクトリは ~/project です。
以下のコマンドを実行して、ロード済みかつアクティブなサービスユニットをすべて一覧表示します。
systemctl list-units --type=service
以下のような出力が表示され、さまざまなサービスとその状態を確認できます。
UNIT LOAD ACTIVE SUB DESCRIPTION
atd.service loaded active running Job spooling tools
auditd.service loaded active running Security Auditing Service
chronyd.service loaded active running NTP client/server
crond.service loaded active running Command Scheduler
dbus-broker.service loaded active running D-Bus System Message Bus
...output omitted...
出力の各列の意味は以下の通りです。
- UNIT: サービスユニットの名前。通常は
.serviceで終わります。 - LOAD:
systemdデーモンがユニットの設定を正常に解析し、メモリにロードできたかどうかを示します。loadedは成功したことを意味します。 - ACTIVE: ユニットの高度なアクティベーション状態です。
activeは一般的にユニットが正常に開始されたことを意味します。 - SUB: より詳細な情報を提供する低レベルのアクティベーション状態です。実行中のサービスの場合、
runningが一般的です。 - DESCRIPTION: サービスが何を行うかの簡単な説明です。
q キーを押してコマンドを終了します。
次に、systemctl list-units --type=service に --all オプションを付けることで、アクティベーション状態（アクティブ、非アクティブ、失敗など）に関係なく、すべてのサービスユニットを一覧表示できます。これは、インストールされているが現在実行されていないサービスを確認するのに便利です。
以下のコマンドを実行してください。
systemctl list-units --type=service --all
出力には、inactive やその他の状態にあるサービスも含まれ、より包括的なビューが得られます。
UNIT LOAD ACTIVE SUB DESCRIPTION
atd.service loaded active running Job spooling tools
auditd.service loaded active running Security Auditing ...
auth-rpcgss-module.service loaded inactive dead Kernel Module ...
chronyd.service loaded active running NTP client/server
cpupower.service loaded inactive dead Configure CPU power ...
crond.service loaded active running Command Scheduler
dbus-broker.service loaded active running D-Bus System Message Bus
● display-manager.service not-found inactive dead display-manager.service
...output omitted...
最後に、ロードされていないものやアクティブでないものを含め、インストールされているすべてのユニットファイルのステータスを確認するには、systemctl list-unit-files --type=service を使用します。このコマンドは、サービスが enabled（起動時に開始）、disabled（起動時に開始しない）、static（直接有効化できないが他のユニットによって開始される可能性がある）、または masked（開始が禁止されている）のいずれであるかを表示します。
以下のコマンドを実行してください。
systemctl list-unit-files --type=service
以下のような出力が表示され、各サービスユニットファイルの STATE と VENDOR PRESET が確認できます。
UNIT FILE STATE VENDOR PRESET
arp-ethers.service disabled disabled
atd.service enabled enabled
auditd.service enabled enabled
auth-rpcgss-module.service static -
autovt@.service alias -
blk-availability.service disabled disabled
...output omitted...
このコマンドは、どのサービスがシステム起動時に自動的に開始されるように設定されているかを理解するのに特に役立ちます。
systemctl status を使用した特定のサービスのステータス確認
このステップでは、systemctl status コマンドを使用して、特定のサービスの詳細なステータスを確認する方法を学びます。このコマンドは、サービスが実行中かどうか、プロセスID、メモリ使用量、最近のログエントリなど、サービスに関する包括的な情報を提供します。
例として crond.service（cron デーモン）を使用します。cron デーモンは、スケジュールされたタスクを処理する一般的なサービスです。
RHEL 環境でターミナルを開き、~/project ディレクトリにいることを確認してください。
以下のコマンドを実行して、crond.service のステータスを確認します。
systemctl status crond.service
以下のような詳細な出力が表示されます。
● crond.service - Command Scheduler
Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; preset: enabled)
Active: active (running) since Mon 2022-03-14 05:38:10 EDT; 25min ago
Main PID: 1089 (crond)
Tasks: 1 (limit: 35578)
Memory: 1.2M
CPU: 12ms
CGroup: /system.slice/crond.service
└─1089 /usr/sbin/crond -n
Mar 14 05:38:10 workstation systemd[1]: Started Command Scheduler.
Warning: some journal files were not opened due to insufficient permissions.
出力の主要なフィールドを確認しましょう。
Loaded: サービスユニットの設定ファイルが処理されたかどうかを示します。また、ユニットファイルへのパス (/usr/lib/systemd/system/crond.service) と有効化ステータス (enabledは起動時に開始するように設定されていることを意味します) も表示されます。Active: 非常に重要です。サービスの現在の状態を示します。active (running)は、サービスが現在アクティブで、プロセスが実行中であることを意味します。また、アクティブになってからの経過時間も表示されます。その他の状態には、inactive（実行中ではない）、active (exited)（一度限りのタスクが完了した）、failed（エラーが発生した）などがあります。Main PID: サービスに関連付けられたメインプロセスのプロセスID (PID) とコマンド名です。Tasks: サービスが現在使用しているタスク（スレッド）の数です。Memory: サービスが消費しているメモリ量です。CPU: サービスが消費した CPU 時間です。CGroup: サービスが属するコントロールグループに関する情報で、リソース管理に使用されます。CGroupより下の行には、サービスに関連する最近のログエントリが表示され、起動や進行中のアクティビティに関する洞察が得られます。
systemctl status に加えて、サービスのステータスの特定の側面を素早く確認するためのよりシンプルなコマンドもあります。
サービスがアクティブかどうかを確認する：
systemctl is-active crond.service期待される出力：
activeサービスが有効（起動時に開始するように設定）かどうかを確認する：
systemctl is-enabled crond.service期待される出力：
enabledサービスが失敗したかどうかを確認する：
systemctl is-failed crond.service期待される出力（正常に実行されている場合）：
activeサービスが起動や実行に問題を抱えていた場合、このコマンドは
failedを返します。
これらのコマンドは、systemctl status の詳細な出力が必要ない場合のスクリプト作成やクイックチェックに便利です。
systemctl を使用したサービスの起動、停止、再起動
このステップでは、systemctl コマンドを使用してシステムサービスのライフサイクルを管理する方法を学びます。サービスの起動、停止、再起動を練習します。この演習では、作成するダミーサービスを使用します。このアプローチにより、重要なシステム機能に影響を与えることなく、安全にサービスを操作できます。
まず、単純なサービスユニットファイルを作成します。このファイルは、数秒ごとにログファイルにタイムスタンプを書き込むだけのサービスを定義します。
nano を使用して、systemd システムディレクトリに mytest.service という名前の新しいサービスユニットファイルを直接作成します。
sudo nano /etc/systemd/system/mytest.service
以下の内容を nano エディタに貼り付けます。
[Unit]
Description=My Test Service
After=network.target
[Service]
Type=simple
ExecStart=/bin/bash -c 'while true; do echo "$(date): My Test Service is running." >> /tmp/mytest.log; sleep 5; done'
ExecStop=/bin/bash -c 'echo "$(date): My Test Service stopped." >> /tmp/mytest.log'
Restart=on-failure
[Install]
WantedBy=multi-user.target
[Unit]: ユニットに関する一般的な情報が含まれます。Descriptionは人間が読める名前を提供し、After=network.targetはネットワークが立ち上がった後にこのサービスを開始すべきであることを指定します。[Service]: サービスの動作を定義します。Type=simple:ExecStartコマンドがメインプロセスである単純なサービスタイプを示します。ExecStart: サービス開始時に実行するコマンドです。ここでは、5秒ごとに/tmp/mytest.logにタイムスタンプ付きのメッセージを書き込む bash ループです。ExecStop: サービス停止時に実行するコマンドです。ログに停止メッセージを書き込みます。Restart=on-failure: ゼロ以外のステータスで終了した場合にサービスを再起動するように設定します。
[Install]: サービスのインストール方法に関する情報が含まれます。WantedBy=multi-user.targetは、システムがマルチユーザーランレベルに達したときにこのサービスを開始すべきであることを意味します。
Ctrl+X を押し、Y で確定し、Enter を押してファイルを保存します。
次に、systemd デーモンをリロードして新しいサービスファイルを認識させます。
sudo systemctl daemon-reload
サービスの起動
サービスを開始するには、systemctl start コマンドを使用します。
以下のコマンドを実行して mytest.service を開始します。systemctl 操作には通常 root 権限が必要なため、sudo を使用する必要があることに注意してください。
sudo systemctl start mytest.service
コマンドが成功した場合、即時の出力はありません。
次に、ステータスを確認してサービスが実行中であることを検証します。
systemctl status mytest.service
サービスが active (running) であることを示す出力が表示されるはずです。
● mytest.service - My Test Service
Loaded: loaded (/etc/systemd/system/mytest.service; disabled; preset: disabled)
Active: active (running) since ...
Main PID: ... (bash)
Tasks: 2 (limit: ...)
Memory: ...
CPU: ...
CGroup: /system.slice/mytest.service
├─... /bin/bash -c "while true; do echo \"\$(date): My Test Service is running.\" >> /tmp/mytest.log; sleep 5; done"
└─... sleep 5
...output omitted...
ログファイルを確認して、サービスがメッセージを書き込んでいるか確認することもできます。
tail -f /tmp/mytest.log
以下のように、5秒ごとに新しい行が表示されるはずです。
Tue Jul 22 09:15:09 AM CST 2025: My Test Service is running.
Tue Jul 22 09:15:14 AM CST 2025: My Test Service is running.
Ctrl+C を押して tail を終了します。
サービスの停止
実行中のサービスを停止するには、systemctl stop コマンドを使用します。
以下のコマンドを実行して mytest.service を停止します。
sudo systemctl stop mytest.service
ここでも、即時の出力はありません。
サービスが停止したことを確認します。
systemctl status mytest.service
出力には Active: inactive (dead) と表示されるはずです。
○ mytest.service - My Test Service
Loaded: loaded (/etc/systemd/system/mytest.service; disabled; preset: disabled)
Active: inactive (dead) since ...
...output omitted...
ログファイル /tmp/mytest.log を再度確認します。「My Test Service stopped.」というメッセージが表示され、新しい「running」メッセージが表示されていないはずです。
tail /tmp/mytest.log
出力は以下のようになります。
Tue Jul 22 09:15:24 AM CST 2025: My Test Service is running.
Tue Jul 22 09:15:28 AM CST 2025: My Test Service stopped.
サービスの再起動
サービスを再起動するには、systemctl restart コマンドを使用します。このコマンドは、まずサービスを停止してから再度開始します。これは、サービスの設定を変更し、それを反映させる必要がある場合に便利です。
以下のコマンドを実行して mytest.service を再起動します。
sudo systemctl restart mytest.service
サービスが再び実行中であることを確認します。
systemctl status mytest.service
再び Active: active (running) と表示され、Main PID が新しい番号になっているはずです。これは新しいプロセスが開始されたことを示しています。
● mytest.service - My Test Service
Loaded: loaded (/etc/systemd/system/mytest.service; disabled; preset: disabled)
Active: active (running) since ...
Main PID: ... (bash)
Tasks: 2 (limit: ...)
Memory: ...
CPU: ...
CGroup: /system.slice/mytest.service
├─... /bin/bash -c "while true; do echo \"\$(date): My Test Service is running.\" >> /tmp/mytest.log; sleep 5; done"
└─... sleep 5
...output omitted...
ログファイル /tmp/mytest.log を確認し、サービスが「running」メッセージの書き込みを再開したことを確認します。
tail -f /tmp/mytest.log
「stopped」メッセージの後に新しい「running」メッセージが表示されるはずです。
Tue Jul 22 09:15:28 AM CST 2025: My Test Service stopped.
Tue Jul 22 09:15:40 AM CST 2025: My Test Service is running.
Ctrl+C を押して tail を終了します。
サービスへの設定変更の適用
このステップでは、サービス設定の再読み込みについて学びます。一部のサービスは、完全な再起動を必要とせずに設定ファイルの変更を適用できます。これは「サービスの再読み込み（reloading）」と呼ばれます。再読み込みは、サービスのダウンタイムを回避し、既存の接続や状態を保持できるため、一般的に再起動よりも推奨されます。サービスが再読み込みされる際、PID が変化する完全な再起動とは異なり、プロセスID (PID) は通常維持されます。
前のステップの mytest.service を引き続き使用します。動作を変更し、再読み込みを試みて何が起こるかを確認します。
まず、mytest.service が実行中であることを確認してください。実行されていない場合は開始します。
sudo systemctl start mytest.service
ステータスを確認し、Main PID をメモしておきます。
systemctl status mytest.service
次に、mytest.service ファイルを修正して、ログに記録されるメッセージと間隔を変更します。ログメッセージを変更し、sleep の時間を 5 秒から 2 秒に変更します。
nano で /etc/systemd/system/mytest.service を開きます。
sudo nano /etc/systemd/system/mytest.service
ExecStart 行を以下のように変更し、メッセージと sleep 時間を 2 秒に変更します。
[Unit]
Description=My Test Service
After=network.target
[Service]
Type=simple
ExecStart=/bin/bash -c 'while true; do echo "$(date): My Test Service (reloaded) is running." >> /tmp/mytest.log; sleep 2; done'
ExecStop=/bin/bash -c 'echo "$(date): My Test Service stopped." >> /tmp/mytest.log'
Restart=on-failure
[Install]
WantedBy=multi-user.target
Ctrl+X、Y、Enter を押してファイルを保存します。
変更を保存した後、サービスの設定が変更されたことを systemd に通知する必要があります。
sudo systemctl daemon-reload
次に、サービスを再読み込みして変更を適用してみます。
sudo systemctl reload mytest.service
おそらくエラーが発生します。
Failed to reload mytest.service: Job type reload is not applicable for unit mytest.service.
このエラーは、単純なサービスが再読み込みリクエストを処理するように設定されていないために発生します。サービスが再読み込み可能であるためには、ユニットファイルに ExecReload ディレクティブが含まれている必要があり、設定を再読み込みするために実行するコマンドを指定する必要があります。mytest.service にはこれがないため、systemd は再読み込み方法を知りません。
このような状況では、systemd は便利なコマンド reload-or-restart を提供しています。このコマンドはサービスの再読み込みを試みますが、再読み込みがサポートされていない場合は、サービスの再起動にフォールバックします。これは、設定変更を適用するためのより安全で効果的な方法であることがよくあります。
今すぐ reload-or-restart を使用してみましょう。
sudo systemctl reload-or-restart mytest.service
このコマンドは成功するはずです。次に、サービスのステータスを再度確認します。
systemctl status mytest.service
Main PID に注目してください。サービスが再起動された（再読み込みできなかったため）ため、Main PID が新しい番号になっていることに気づくでしょう。これは、古いプロセスが停止され、更新された設定で新しいプロセスが開始されたことを確認するものです。
最後に、/tmp/mytest.log ファイルを確認して、変更が適用されたか確認します。
tail -f /tmp/mytest.log
2秒ごとに新しいログメッセージ「My Test Service (reloaded) is running.」が表示されるはずです。Ctrl+C を押して tail を終了します。
systemctl を使用した起動時のサービスの有効化と無効化
このステップでは、システム起動時にサービスが自動的に開始されるように設定（有効化）したり、起動時に開始されないように設定（無効化）したりする方法を学びます。これはシステムリソースを管理し、システム起動時に必要なサービスが利用可能であることを保証するために不可欠です。
一般的な systemd 環境では、サービスを有効化すると、適切な systemd 設定ディレクトリ（例: /etc/systemd/system/multi-user.target.wants/）に、サービスのユニットファイルを指すシンボリックリンクが作成されます。サービスを無効化すると、これらのリンクが削除されます。
systemd が伝統的な意味で完全に動作していない可能性があるコンテナ環境にいるため、enable および disable コマンドは、コンテナの再起動をまたいで永続化する /etc/systemd/system ディレクトリ内の実際のシンボリックリンクを作成しない場合があります。しかし、systemctl は依然としてこれらのコマンドを処理し、内部状態を更新します。これが私たちが観察するものです。
このデモンストレーションには引き続き mytest.service を使用します。
まず、前のステップから mytest.service が停止していることを確認してください。
sudo systemctl stop mytest.service
サービスの有効化
サービスを有効化するには、systemctl enable コマンドを使用します。このコマンドは、システム起動時にサービスが自動的に開始されるように設定します。
以下のコマンドを実行して mytest.service を有効化します。
sudo systemctl enable mytest.service
完全な systemd 環境ではシンボリックリンクが作成されることを示す、以下のような出力が表示される場合があります。
Created symlink /etc/systemd/system/multi-user.target.wants/mytest.service → /etc/systemd/system/mytest.service.
次に、systemctl is-enabled を使用してサービスが有効になっていることを確認します。
systemctl is-enabled mytest.service
期待される出力：
enabled
これにより、systemctl が mytest.service を起動時に有効であるとみなしていることが確認できます。
--now オプションを使用して、サービスの有効化と開始を1つのコマンドにまとめることもできます。これは、サービスが即座に実行され、将来の起動時にも開始されるように設定するための便利な方法です。
まず、--now のデモンストレーションの準備として無効化します。
sudo systemctl disable mytest.service
次に、有効化と開始を同時に行います。
sudo systemctl enable --now mytest.service
ステータスと有効化状態を確認します。
systemctl status mytest.service
systemctl is-enabled mytest.service
status コマンドから Active: active (running) が、is-enabled コマンドから enabled が表示されるはずです。
サービスの無効化
サービスを無効化するには、systemctl disable コマンドを使用します。このコマンドは、システム起動時にサービスを開始させる設定を削除します。
以下のコマンドを実行して mytest.service を無効化します。
sudo systemctl disable mytest.service
シンボリックリンクの削除を示す出力が表示される場合があります。
Removed /etc/systemd/system/multi-user.target.wants/mytest.service.
次に、サービスが無効になっていることを確認します。
systemctl is-enabled mytest.service
期待される出力：
disabled
有効化と同様に、--now オプションを使用して、サービスの無効化と停止を組み合わせることができます。これにより、サービスが即座に停止され、将来の起動時に開始されるのを防ぎます。
sudo systemctl disable --now mytest.service
ステータスと有効化状態を確認します。
systemctl status mytest.service
systemctl is-enabled mytest.service
status コマンドから Active: inactive (dead) が、is-enabled コマンドから disabled が表示されるはずです。
これで、サービスの有効化と無効化のデモンストレーションは終了です。実際の systemd 環境では、これらのコマンドが起動設定を直接操作することを覚えておいてください。
systemctl を使用したサービスのマスキングとアンマスキング
この最後のステップでは、サービスのマスキング（masking）とアンマスキング（unmasking）について学びます。サービスをマスクすることは、手動または起動時に自動的に開始されるのを防ぐ強力な方法です。
サービスをマスクすると、systemd は /etc/systemd/system/<service-name>.service から /dev/null へのシンボリックリンクを作成し、実質的にサービスユニットファイルを systemd から利用できないようにします。これは disable よりも強力な代替手段です。
このメカニズムは、パッケージがサービスファイルをインストールする場所である /usr/lib/systemd/system で定義されているサービスに対して最も効果的です。mask コマンドは、/etc/systemd/system に上書きする「空の」ファイルを作成します。しかし、すでに発見したように、/etc/systemd/system に直接作成したサービス（mytest.service など）をマスクしようとすると、データ損失の原因となる既存の設定ファイルを上書きしないように設計されているため、コマンドが失敗する可能性があります。
マスキングを正しくデモンストレーションするために、既存のサービス atd.service を使用します。
まず、atd.service の現在のステータスを確認します。アクティブで有効になっているはずです。
systemctl status atd.service
出力は以下のようになり、サービスがアクティブで実行中であることがわかります。
● atd.service - Deferred execution scheduler
Loaded: loaded (/usr/lib/systemd/system/atd.service; enabled; preset: enabled)
Active: active (running) since Tue 2025-07-22 09:13:06 CST; 22min ago
Docs: man:atd(8)
Main PID: 1222 (atd)
Tasks: 1 (limit: 22509)
Memory: 900.0K
CPU: 5ms
CGroup: /system.slice/atd.service
└─1222 /usr/sbin/atd -f
サービスのマスキング
サービスをマスクする前に停止するのが良い習慣です。
sudo systemctl stop atd.service
次に、以下のコマンドを実行して atd.service をマスクします。
sudo systemctl mask atd.service
/dev/null へのシンボリックリンクの作成を示す出力が表示されます。
Created symlink /etc/systemd/system/atd.service → /dev/null.
次に、マスクされたサービスを開始してみます。
sudo systemctl start atd.service
サービスがマスクされていることを示すエラーメッセージが表示されます。
Failed to start atd.service: Unit atd.service is masked.
systemctl list-unit-files を使用してサービスのステータスを確認することもできます。
systemctl list-unit-files --type=service | grep atd.service | tee ~/project/atd-mask-state.txt
出力には atd.service が masked と表示されるはずです。
atd.service masked enabled
これにより、サービスが現在マスクされており、開始できないことが確認できます。
サービスのアンマスキング
サービスをアンマスクするには、systemctl unmask コマンドを使用します。このコマンドは /dev/null へのシンボリックリンクを削除し、/usr/lib/systemd/system から元のサービスファイルを復元します。
以下のコマンドを実行して atd.service をアンマスクします。
sudo systemctl unmask atd.service
シンボリックリンクの削除を示す出力が表示されます。
Removed "/etc/systemd/system/atd.service".
アンマスクした後、サービスを再度開始してください。unmask は /dev/null リンクを削除するだけで、サービスを再起動してはくれないためです。
sudo systemctl start atd.service
次に、サービスのステータスを確認します。
systemctl status atd.service
Active: active (running) と表示されるはずです。
● atd.service - Deferred execution scheduler
Loaded: loaded (/usr/lib/systemd/system/atd.service; enabled; preset: enabled)
Active: active (running) since Tue 2025-07-22 09:36:10 CST; 2s ago
Docs: man:atd(8)
Main PID: 7372 (atd)
Tasks: 1 (limit: 22509)
Memory: 868.0K
CPU: 6ms
CGroup: /system.slice/atd.service
└─7372 /usr/sbin/atd -f
これで、サービスとデーモンの制御に関する実験は終了です。systemctl を使用してサービスを表示、開始、停止、再起動、再読み込み、有効化、無効化、マスク、アンマスクする方法を学びました。
まとめ
この実験では、systemd が主要な init システムではない可能性があるコンテナ環境であっても、systemctl コマンドを使用してシステムサービスを管理する実践的な経験を積みました。systemctl list-units --type=service を使用してロード済みおよびアクティブなサービスユニットをすべて一覧表示する方法を学び、UNIT、LOAD、ACTIVE、SUB 列を使用してサービスの状態を解釈する方法を理解しました。
さらに、systemctl status を使用した特定のサービスのステータス確認や、サービスの起動・停止・再起動によるライフサイクル管理といった重要なサービス管理操作を学びました。また、サービス設定の再読み込み、起動時の動作を制御するためのサービスの有効化と無効化、そしてサービスの起動を防ぐためのマスキングとアンマスキングという高度な概念についても扱いました。この包括的なスキルセットは、RHEL システム上のサービスを管理するための強固な基盤となります。
