この実験では、systemctl コマンドを使用して RHEL 上のシステムサービスを管理する実践的な経験を積みます。ロードされアクティブなすべてのサービスを表示し、特定のサービスのステータスを確認し、それらを起動、停止、再起動することで実行時の動作を制御する方法を学びます。さらに、サービス設定のリロード方法、起動時の自動起動を有効または無効にする方法を探り、サービスの起動を防ぐためのマスキングとアンマスキングの高度な概念を理解します。
この実践的なガイドは、システム管理に不可欠なスキルを習得し、RHEL システムの運用に不可欠なサービスのライフサイクルを効果的に監視および管理できるようにします。
このステップでは、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...出力の列を分析しましょう。
.service で終わります。systemd デーモンがユニットの設定を正常に解析してメモリにロードしたかどうかを示します。loaded は成功したことを意味します。active は通常、ユニットが正常に起動したことを意味します。running が一般的です。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 コマンドを使用して特定のサービスの詳細なステータスを確認する方法を学びます。このコマンドは、サービスが実行中かどうか、そのプロセス 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 コマンドを使用してシステムサービスのライフサイクルを管理する方法を学びます。サービスの開始、停止、再起動を練習します。この演習では、作成するダミーサービスを使用します。このアプローチにより、重要なシステム機能に影響を与えることなく、安全にサービスを操作できます。
まず、簡単なサービスユニットファイルを作成しましょう。このファイルは、数秒ごとにタイムスタンプをログファイルに書き込むサービスを定義します。
nano を使用して、systemd システムディレクトリに直接 mytest.service という名前の新しいサービスユニットファイルを作成します。
sudo nano /etc/systemd/system/mytest.servicenano エディタに以下の内容を貼り付けます。
[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.serviceActive: 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 を終了します。
このステップでは、サービスの構成をリロードする方法について学びます。一部のサービスは、完全に再起動することなく、構成ファイルの変更を適用できます。これは、サービスを「リロード」として知られています。リロードは、サービスの中断を回避し、既存の接続や状態を維持するため、一般的に再起動よりも推奨されます。サービスがリロードされると、完全な再起動とは異なり、通常、そのプロセス ID（PID）は同じままです。
前のステップで使用した mytest.service を引き続き使用します。その動作を変更し、リロードを試みて何が起こるかを確認します。
まず、mytest.service が実行されていることを確認します。実行されていない場合は、開始します。
sudo systemctl start mytest.serviceそのステータスを確認し、Main PID に注意してください。
systemctl status mytest.service次に、ログメッセージと間隔を変更するために、mytest.service ファイルを変更しましょう。ログメッセージと sleep の期間を変更します。
nano で /etc/systemd/system/mytest.service を開きます。
sudo nano /etc/systemd/system/mytest.serviceExecStart 行を以下のように変更し、メッセージと sleep の時間を 5 秒から 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.targetCtrl+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.serviceMain PID を観察してください。サービスが再起動されたため（リロードできなかったため）、Main PID が 新しい 番号になっていることに気づくでしょう。これは、古いプロセスが停止され、更新された構成で新しいプロセスが開始されたことを確認します。
最後に、変更が有効になったかどうかを確認するために /tmp/mytest.log ファイルを確認しましょう。
tail -f /tmp/mytest.log「My Test Service (reloaded) is running.」という新しいログメッセージが 2 秒ごとに表示されるはずです。Ctrl+C を押して tail を終了します。
このステップでは、サービスを起動時に自動的に開始するように構成する（有効化）方法、または起動時に開始しないように防止する（無効化）方法を学びます。これは、システムリソースを管理し、システム起動時に必要なサービスが利用可能であることを保証するために重要です。
典型的な 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 オプションを使用して、サービスを有効化し、同時に開始することもできます。これは、サービスがすぐに実行され、将来の起動時に開始するように構成されていることを確認する便利な方法です。
まず、--now デモンストレーションの準備として無効化しましょう。
sudo systemctl disable mytest.service次に、同時に有効化して開始します。
sudo systemctl enable --now mytest.serviceそのステータスと有効化を確認します。
systemctl status mytest.service
systemctl is-enabled mytest.servicestatus コマンドからは 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.servicestatus コマンドからは Active: inactive (dead) が、is-enabled コマンドからは disabled が表示されるはずです。
これで、サービスの有効化と無効化のデモンストレーションは終了です。実際の systemd 環境では、これらのコマンドは起動構成を直接操作することに注意してください。
この最後のステップでは、サービスのマスクとアンマスクについて学びます。サービスをマスクすることは、手動または起動時に自動的に開始されるのを防ぐ強力な方法です。
サービスをマスクすると、systemd は /etc/systemd/system/<service-name>.service から /dev/null へのシンボリックリンクを作成し、サービスのユニットファイルを事実上 systemd で利用できなくします。これは disable よりも強力な代替手段です。
このメカニズムは、パッケージがサービスファイルをインストールする /usr/lib/systemd/system に定義されているサービスで最も効果的に機能します。mask コマンドは、/etc/systemd/system にオーバーライドする「空の」ファイルを作成します。しかし、ご存知のように、自分で作成したサービス（例：mytest.service）を /etc/systemd/system に直接マスクしようとすると、既存の構成ファイルを上書きしないように設計されているため、コマンドが失敗する可能性があります。これはデータ損失を引き起こすためです。
マスクを正しくデモンストレーションするために、既存のサービスである 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出力は 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".次に、systemctl list-unit-files を使用してサービスのステータスを再度確認します。
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 システムでのサービス管理の強固な基盤を提供します。
