Systemctlを使用してSystemdサービスとユニットを管理する方法

投稿日: 2019-11-08 2022-10-17
タグ: System Tools

序章

systemd は、Linuxディストリビューションの新しい標準に広くなっているinitシステムおよびシステムマネージャーです。採用が多いため、 systemd サーバーの管理がかなり簡単になるので、トラブルに見合うだけの価値があります。を構成するツールとデーモンについて学び、使用する systemd それが提供するパワー、柔軟性、および機能をよりよく理解するのに役立ちます。あるいは、少なくとも面倒な作業を減らすのに役立ちます。

このガイドでは、 systemctl コマンド。これは、initシステムを制御するための中央管理ツールです。サービスの管理方法、ステータスの確認方法、システム状態の変更方法、および構成ファイルの操作方法について説明します。

ただし、注意してください systemd 多くのLinuxディストリビューションのデフォルトのinitシステムになっていますが、すべてのディストリビューションに普遍的に実装されているわけではありません。このチュートリアルを実行しているときに、端末がエラーを出力した場合 bash: systemctl is not installed その場合、マシンに別のinitシステムがインストールされている可能性があります。

サービス管理

initシステムの基本的な目的は、Linuxカーネルの起動後に起動する必要のあるコンポーネント（従来は「ユーザーランド」コンポーネントと呼ばれていました）を初期化することです。 initシステムは、システムの実行中の任意の時点でサーバーのサービスとデーモンを管理するためにも使用されます。それを念頭に置いて、いくつかの基本的なサービス管理操作から始めます。

の systemd、ほとんどのアクションのターゲットは「ユニット」です。これは、 systemd 管理する方法を知っています。ユニットは、それらが表すリソースのタイプによって分類され、ユニットファイルと呼ばれるファイルで定義されます。各ユニットのタイプは、ファイルの最後にあるサフィックスから推測できます。

サービス管理タスクの場合、ターゲットユニットはサービスユニットになります。サービスユニットには、接尾辞が .service. ただし、ほとんどのサービス管理コマンドでは、実際には省略できます。 .service 接尾辞、 systemd は、サービス管理コマンドを使用するときにサービスを操作する可能性があることを認識できるほど賢いです。

サービスの開始と停止

開始するには systemd サービスは、サービスのユニットファイルで命令を実行し、 start 指図。 root以外のユーザーとして実行している場合は、次を使用する必要があります。 sudo これはオペレーティングシステムの状態に影響するため、次のようになります。

sudo systemctl start application.service

上で述べたように、 systemd 探すことを知っている *.service サービス管理コマンドのファイル。コマンドは次のように入力できます。

sudo systemctl start application

一般的な管理には上記の形式を使用できますが、わかりやすくするために、 .service 残りのコマンドの接尾辞。操作しているターゲットについて明示します。

現在実行中のサービスを停止するには、 stop 代わりにコマンド：

sudo systemctl stop application.service

再起動とリロード

実行中のサービスを再開するには、 restart 指図：

sudo systemctl restart application.service

問題のアプリケーションが（再起動せずに）構成ファイルをリロードできる場合は、 reload そのプロセスを開始するコマンド：

sudo systemctl reload application.service

サービスに構成をリロードする機能があるかどうかわからない場合は、 reload-or-restart 指図。これにより、可能な場合は構成がインプレースで再ロードされます。それ以外の場合は、サービスが再起動されるため、新しい構成が取得されます。

sudo systemctl reload-or-restart application.service

サービスの有効化と無効化

上記のコマンドは、現在のセッション中にサービスを開始または停止する場合に役立ちます。伝えるために systemd 起動時にサービスを自動的に開始するには、サービスを有効にする必要があります。

起動時にサービスを開始するには、 enable 指図：

sudo systemctl enable application.service

これにより、システムのサービスファイルのコピーからシンボリックリンクが作成されます（通常は /lib/systemd/system また /etc/systemd/system）ディスク上の場所に systemd 自動起動ファイルを探します（通常は /etc/systemd/system/some_target.target.wants. このガイドの後半で、ターゲットが何であるかについて説明します）。

サービスが自動的に開始されないようにするには、次のように入力します。

sudo systemctl disable application.service

これにより、サービスを自動的に開始する必要があることを示すシンボリックリンクが削除されます。

サービスを有効にしても、現在のセッションではサービスが開始されないことに注意してください。サービスを開始し、起動時に有効にする場合は、両方を発行する必要があります start と enable コマンド。

サービスのステータスを確認する

システム上のサービスのステータスを確認するには、 status 指図：

systemctl status application.service

これにより、サービス状態、cgroup階層、および最初の数行のログが提供されます。

たとえば、Nginxサーバーのステータスを確認すると、次のような出力が表示される場合があります。

Output● nginx.service - A high performance web server and a reverse proxy server
   Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2015-01-27 19:41:23 EST; 22h ago
 Main PID: 495 (nginx)
   CGroup: /system.slice/nginx.service
           ├─495 nginx: master process /usr/bin/nginx -g pid /run/nginx.pid; error_log stderr;
           └─496 nginx: worker process
Jan 27 19:41:23 desktop systemd[1]: Starting A high performance web server and a reverse proxy server...
Jan 27 19:41:23 desktop systemd[1]: Started A high performance web server and a reverse proxy server.

これにより、アプリケーションの現在のステータスの概要がわかり、問題や必要なアクションが通知されます。

特定の状態をチェックする方法もあります。たとえば、ユニットが現在アクティブ（実行中）であるかどうかを確認するには、 is-active 指図：

systemctl is-active application.service

これにより、現在のユニット状態が返されます。これは通常、 active また inactive. アクティブな場合、終了コードは「0」になり、シェルスクリプトでの結果の解析が簡単になります。

ユニットが有効になっているかどうかを確認するには、 is-enabled 指図：

systemctl is-enabled application.service

これにより、サービスが enabled また disabled コマンドの質問への回答に応じて、終了コードを「0」または「1」に再度設定します。

3番目のチェックは、ユニットが故障状態にあるかどうかです。これは、問題のユニットの起動に問題があったことを示しています。

systemctl is-failed application.service

これは戻ります active 正常に動作している場合、または failed エラーが発生した場合。意図的に停止させた場合、復帰する場合があります unknown また inactive. 終了ステータス「0」は障害が発生したことを示し、終了ステータス「1」はその他のステータスを示します。

システム状態の概要

これまでのコマンドは、単一のサービスを管理するのに役立ちましたが、システムの現在の状態を調べるのにはあまり役立ちません。いくつかあります systemctl この情報を提供するコマンド。

現在のユニットの一覧表示

すべてのアクティブなユニットのリストを表示するには systemd 知っている、私たちは使用することができます list-units 指図：

systemctl list-units

これにより、すべてのユニットのリストが表示されます。 systemd 現在、システムでアクティブになっています。出力は次のようになります。

OutputUNIT                                      LOAD   ACTIVE SUB     DESCRIPTION
atd.service                               loaded active running ATD daemon
avahi-daemon.service                      loaded active running Avahi mDNS/DNS-SD Stack
dbus.service                              loaded active running D-Bus System Message Bus
dcron.service                             loaded active running Periodic Command Scheduler
dkms.service                              loaded active exited  Dynamic Kernel Modules System
[email protected]                        loaded active running Getty on tty1
. . .

出力には次の列があります。

UNIT ： systemd ユニット名
LOAD ：ユニットの構成がによって解析されたかどうか systemd. ロードされたユニットの構成はメモリに保持されます。
ACTIVE ：ユニットがアクティブかどうかに関する要約状態。これは通常、ユニットが正常に起動したかどうかを判断するためのかなり基本的な方法です。
SUB ：これは、ユニットに関するより詳細な情報を示す下位レベルの状態です。これは多くの場合、ユニットのタイプ、状態、およびユニットが実行される実際の方法によって異なります。
DESCRIPTION ：ユニットが何であるか/何をするかについての短いテキストの説明。

以来 list-units コマンドはデフォルトでアクティブなユニットのみを表示し、上記のすべてのエントリは表示されます loaded LOAD列と active アクティブ列にあります。この表示は、実際にはのデフォルトの動作です。 systemctl 追加のコマンドなしで呼び出された場合、呼び出すと同じことが表示されます systemctl 引数なし：

systemctl

わかります systemctl フラグを追加してさまざまな情報を出力します。たとえば、すべてのユニットを表示するには systemd がロードされた（またはロードを試みた）場合、それらが現在アクティブであるかどうかに関係なく、 --all このようなフラグ：

systemctl list-units --all

これにより、次のようなユニットが表示されます systemd システム上の現在の状態に関係なく、ロードされたか、ロードを試みました。一部のユニットは実行後に非アクティブになり、一部のユニットは systemd ロードしようとしたが、ディスク上で見つからなかった可能性があります。

他のフラグを使用して、これらの結果をフィルタリングできます。たとえば、 --state= 表示したいLOAD、ACTIVE、またはSUB状態を示すフラグ。あなたは維持する必要があります --all フラグを立てて systemctl 非アクティブなユニットを表示できるようにします。

systemctl list-units --all --state=inactive

もう1つの一般的なフィルターは --type= フィルター。わかります systemctl 関心のあるタイプの単位のみを表示します。たとえば、アクティブなサービスユニットのみを表示するには、次を使用できます。

systemctl list-units --type=service

すべてのユニットファイルの一覧表示

The list-units コマンドは、 systemd 解析してメモリにロードしようとしました。以来 systemd 必要と思われるユニットのみを読み取ります。これには、システムで使用可能なすべてのユニットが含まれるとは限りません。内のすべての使用可能なユニットファイルを表示するには systemd パスを含むパス systemd ロードを試みていません、あなたは使用することができます list-unit-files 代わりにコマンド：

systemctl list-unit-files

単位は、次のようなリソースの表現です。 systemd 知っている。以来 systemd このビューのすべてのユニット定義を必ずしも読み取ったわけではなく、ファイル自体に関する情報のみを表示します。出力には、ユニットファイルと状態の2つの列があります。

OutputUNIT FILE                                  STATE
proc-sys-fs-binfmt_misc.automount          static
dev-hugepages.mount                        static
dev-mqueue.mount                           static
proc-fs-nfsd.mount                         static
proc-sys-fs-binfmt_misc.mount              static
sys-fs-fuse-connections.mount              static
sys-kernel-config.mount                    static
sys-kernel-debug.mount                     static
tmp.mount                                  static
var-lib-nfs-rpc_pipefs.mount               static
org.cups.cupsd.path                        enabled
. . .

状態は通常 enabled, disabled, static、また masked. このコンテキストでは、静的とは、ユニットファイルに install ユニットを有効にするために使用されるセクション。そのため、これらのユニットを有効にすることはできません。通常、これは、ユニットが1回限りのアクションを実行するか、別のユニットの依存関係としてのみ使用され、単独で実行されるべきではないことを意味します。

何をカバーします masked 瞬間を意味します。

ユニット管理

これまで、サービスを利用して、ユニットとユニットファイルに関する情報を表示してきました。 systemd 知っている。ただし、いくつかの追加コマンドを使用して、ユニットに関するより具体的な情報を見つけることができます。

ユニットファイルの表示

ユニットファイルを表示するには systemd システムにロードされている場合は、 cat コマンド（これはで追加されました systemd バージョン209）。たとえば、のユニットファイルを表示するには atd スケジューリングデーモン、次のように入力できます。

systemctl cat atd.service

Output[Unit]
Description=ATD daemon
[Service]
Type=forking
ExecStart=/usr/bin/atd
[Install]
WantedBy=multi-user.target

出力は、現在実行中のユニットファイルです。 systemd 処理する。これは、ユニットファイルを最近変更した場合、またはユニットファイルフラグメントの特定のオプションをオーバーライドする場合に重要になる可能性があります（これについては後で説明します）。

依存関係の表示

ユニットの依存関係ツリーを表示するには、 list-dependencies 指図：

systemctl list-dependencies sshd.service

これにより、問題のユニットを起動するために処理する必要のある依存関係をマッピングする階層が表示されます。このコンテキストでは、依存関係には、その上のユニットによって必要とされる、または必要とされるユニットが含まれます。

Outputsshd.service
├─system.slice
└─basic.target
  ├─microcode.service
  ├─rhel-autorelabel-mark.service
  ├─rhel-autorelabel.service
  ├─rhel-configure.service
  ├─rhel-dmesg.service
  ├─rhel-loadmodules.service
  ├─paths.target
  ├─slices.target
. . .

再帰的な依存関係は、 .target システムの状態を示す単位。すべての依存関係を再帰的に一覧表示するには、 --all 国旗。

逆依存関係（指定されたユニットに依存するユニット）を表示するには、 --reverse コマンドにフラグを立てます。便利な他のフラグは --before と --after フラグ。指定されたユニットに依存するユニットを、それぞれ前後から表示するために使用できます。

ユニットのプロパティを確認する

ユニットの低レベルのプロパティを表示するには、 show 指図。これにより、指定されたユニットに設定されているプロパティのリストが表示されます。 key=value フォーマット：

systemctl show sshd.service

OutputId=sshd.service
Names=sshd.service
Requires=basic.target
Wants=system.slice
WantedBy=multi-user.target
Conflicts=shutdown.target
Before=shutdown.target multi-user.target
After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice
Description=OpenSSH server daemon
. . .

単一のプロパティを表示する場合は、 -p プロパティ名のフラグ。たとえば、 sshd.service ユニットには、次のように入力できます。

systemctl show sshd.service -p Conflicts

OutputConflicts=shutdown.target

ユニットのマスキングとアンマスキング

サービス管理のセクションで、サービスを停止または無効にする方法を見ましたが、 systemd また、ユニットを完全に起動不能として、自動または手動でリンクすることにより、ユニットをマークする機能もあります。 /dev/null. これはユニットのマスキングと呼ばれ、 mask 指図：

sudo systemctl mask nginx.service

これにより、マスクされている限り、Nginxサービスが自動または手動で開始されなくなります。

あなたがチェックした場合 list-unit-files、サービスがマスクされたものとしてリストされていることがわかります。

systemctl list-unit-files

Output. . .
kmod-static-nodes.service              static
ldconfig.service                       static
mandb.service                          static
messagebus.service                     static
nginx.service                          masked
quotaon.service                        static
rc-local.service                       static
rdisc.service                          disabled
rescue.service                         static
. . .

サービスを開始しようとすると、次のようなメッセージが表示されます。

sudo systemctl start nginx.service

OutputFailed to start nginx.service: Unit nginx.service is masked.

ユニットのマスクを解除して再び使用できるようにするには、 unmask 指図：

sudo systemctl unmask nginx.service

これにより、ユニットが以前の状態に戻り、起動または有効化できるようになります。

ユニットファイルの編集

ユニットファイルの特定の形式はこのチュートリアルの範囲外ですが、 systemctl 調整が必要な場合にユニットファイルを編集および変更するための組み込みメカニズムを提供します。この機能はで追加されました systemd バージョン218。

The edit コマンドは、デフォルトで、問題のユニットのユニットファイルスニペットを開きます。

sudo systemctl edit nginx.service

これは、ユニット定義にディレクティブをオーバーライドまたは追加するために使用できる空白のファイルになります。ディレクトリは、内に作成されます /etc/systemd/system ユニットの名前を含むディレクトリ .d 添付。たとえば、 nginx.service、というディレクトリ nginx.service.d 作成されます。

このディレクトリ内に、というスニペットが作成されます override.conf. ユニットがロードされると、 systemd メモリ内で、オーバーライドスニペットを完全なユニットファイルとマージします。スニペットのディレクティブは、元のユニットファイルにあるディレクティブよりも優先されます。

スニペットを作成する代わりにユニットファイル全体を編集したい場合は、 --full 国旗：

sudo systemctl edit --full nginx.service

これにより、現在のユニットファイルがエディターにロードされ、そこで変更できます。エディターが終了すると、変更されたファイルは次のように書き込まれます。 /etc/systemd/system、これはシステムのユニット定義よりも優先されます（通常はどこかにあります） /lib/systemd/system).

行った追加を削除するには、ユニットの .d 構成ディレクトリまたは変更されたサービスファイル /etc/systemd/system. たとえば、スニペットを削除するには、次のように入力します。

sudo rm -r /etc/systemd/system/nginx.service.d

完全に変更されたユニットファイルを削除するには、次のように入力します。

sudo rm /etc/systemd/system/nginx.service

ファイルまたはディレクトリを削除した後、リロードする必要があります systemd これらのファイルを参照しようとせず、システムコピーの使用に戻るように処理します。これを行うには、次のように入力します。

sudo systemctl daemon-reload

ターゲットを使用したシステム状態（ランレベル）の調整

ターゲットは、システム状態または同期ポイントを記述する特別なユニットファイルです。他のユニットと同様に、ターゲットを定義するファイルは、サフィックスで識別できます。この場合は、 .target. ターゲットはそれ自体ではあまり機能しませんが、代わりに他のユニットをグループ化するために使用されます。

これは、他のinitシステムがランレベルを使用するのと同じように、システムを特定の状態にするために使用できます。これらは、特定の機能が使用可能な場合の参照として使用され、その状態を生成するために必要な個々のユニットではなく、目的の状態を指定できます。

たとえば、 swap.target これは、スワップを使用する準備ができていることを示すために使用されます。このプロセスの一部であるユニットは、構成で次のことを示すことにより、このターゲットと同期できます。 WantedBy= また RequiredBy= the swap.target. スワップを使用可能にする必要があるユニットは、を使用してこの条件を指定できます。 Wants=, Requires=、と After= それらの関係の性質を示すための仕様。

デフォルトターゲットの取得と設定

The systemd プロセスには、システムの起動時に使用するデフォルトのターゲットがあります。その単一のターゲットからの依存関係のカスケードを満たすと、システムが目的の状態になります。システムのデフォルトのターゲットを見つけるには、次のように入力します。

systemctl get-default

Outputmulti-user.target

別のデフォルトターゲットを設定する場合は、 set-default. たとえば、グラフィカルデスクトップがインストールされていて、システムをデフォルトで起動する場合は、それに応じてデフォルトのターゲットを変更できます。

sudo systemctl set-default graphical.target

利用可能なターゲットの一覧表示

次のように入力すると、システムで使用可能なターゲットのリストを取得できます。

systemctl list-unit-files --type=target

ランレベルとは異なり、一度に複数のターゲットをアクティブにすることができます。アクティブなターゲットは、 systemd ターゲットに関連付けられているすべてのユニットを開始しようとしましたが、それらを再び破壊しようとはしていません。すべてのアクティブなターゲットを表示するには、次のように入力します。

systemctl list-units --type=target

ターゲットの分離

ターゲットに関連付けられているすべてのユニットを開始し、依存関係ツリーの一部ではないすべてのユニットを停止することができます。これを行うために必要なコマンドは、適切に呼び出されます。 isolate. これは、他のinitシステムでランレベルを変更するのと似ています。

たとえば、次のようなグラフィカル環境で操作している場合 graphical.target アクティブな場合、グラフィカルシステムをシャットダウンし、システムを分離することでマルチユーザーコマンドライン状態にすることができます。 multi-user.target. 以来 graphical.target に依存します multi-user.target ただし、その逆ではなく、すべてのグラフィカルユニットが停止します。

重要なサービスを停止していないことを確認するために、この手順を実行する前に、分離しているターゲットの依存関係を確認することをお勧めします。

systemctl list-dependencies multi-user.target

生き続けるユニットに満足したら、次のように入力してターゲットを分離できます。

sudo systemctl isolate multi-user.target

重要なイベントにショートカットを使用する

電源オフや再起動などの重要なイベントに対して定義されたターゲットがあります。でも、 systemctl また、機能を少し追加するショートカットもいくつかあります。

たとえば、システムをレスキュー（シングルユーザー）モードにするには、 rescue 代わりにコマンド isolate rescue.target:

sudo systemctl rescue

これにより、ログインしているすべてのユーザーにイベントについて警告する追加機能が提供されます。

システムを停止するには、 halt 指図：

sudo systemctl halt

完全なシャットダウンを開始するには、 poweroff 指図：

sudo systemctl poweroff

再起動は、 reboot 指図：

sudo systemctl reboot

これらはすべて、ログインしたユーザーにイベントが発生していることを警告します。これは、ターゲットを実行または分離するだけでは実行されません。ほとんどのマシンは、これらの操作のためのより短く、より従来型のコマンドをリンクして、それらが適切に動作するようにすることに注意してください systemd.

たとえば、システムを再起動するには、通常、次のように入力します。

sudo reboot

結論

これで、の基本的な機能のいくつかに精通しているはずです。 systemctl 対話して制御できるコマンド systemd 実例。 The systemctl ユーティリティは、サービスおよびシステム状態管理の主要な相互作用ポイントになります。

その間 systemctl 主にコアで動作します systemd プロセス、他のコンポーネントがあります systemd 他のユーティリティによって制御される生態系。ログ管理やユーザーセッションなどの他の機能は、個別のデーモンと管理ユーティリティによって処理されます（journald/journalctl と logind/loginctl それぞれ）。これらの他のツールやデーモンに慣れるのに時間をかけると、管理が簡単になります。

getdocs

13036