how-to-use-systemctl-to-manage-systemd-services-and-units
前書き
`+ Systemd `は、Linuxマシンの新しい標準になりつつあるinitシステムおよびシステムマネージャーです。 「 systemd 」は、置き換えられている従来の「 SysV +」initシステムよりも改善されているかどうかについてかなりの意見がありますが、大部分のディストリビューションはそれを採用するか、すでに採用しています。
サーバーの管理がかなり簡単になるため、採用が多いため、「+ systemd 」に慣れるのは面倒な価値があります。 ` systemd +`を構成するツールとデーモンを学習して利用すると、それが提供するパワー、柔軟性、機能をよりよく理解するのに役立ちます。
このガイドでは、initシステムを制御するための中央管理ツールである `+ systemctl +`コマンドについて説明します。 サービスの管理方法、ステータスの確認方法、システム状態の変更方法、構成ファイルの操作方法について説明します。
「+ systemd 」は多くのLinuxディストリビューションのデフォルトの初期化システムになっていますが、すべてのディストリビューションに共通して実装されているわけではないことに注意してください。 このチュートリアルを進めると、端末がエラー「 bash：systemctl is not installed +」を出力する場合、マシンに別のinitシステムがインストールされている可能性があります。
サービス管理
initシステムの基本的な目的は、Linuxカーネルの起動後に起動する必要があるコンポーネント（従来は「ユーザーランド」コンポーネントと呼ばれる）を初期化することです。 initシステムは、システムの実行中の任意の時点でサーバーのサービスとデーモンを管理するためにも使用されます。 それを念頭に置いて、簡単なサービス管理操作から始めます。
`+ systemd `では、ほとんどのアクションのターゲットは“ユニット”です。これは、 ` systemd +`が管理方法を知っているリソースです。 ユニットは、それらが表すリソースのタイプによって分類され、ユニットファイルと呼ばれるファイルで定義されます。 各ユニットのタイプは、ファイルの末尾のサフィックスから推測できます。
サービス管理タスクの場合、ターゲットユニットはサービスユニットになり、ユニットファイルには接尾辞「+ .service 」が付きます。 ただし、ほとんどのサービス管理コマンドでは、サービス管理コマンドを使用するときに「 systemd 」がおそらくサービスを操作することを知っているので、「。service +」サフィックスを実際に省略できます。
サービスの開始と停止
`+ systemd `サービスを開始し、サービスのユニットファイル内の命令を実行するには、 ` start `コマンドを使用します。 非rootユーザーとして実行している場合、オペレーティングシステムの状態に影響するため、「 sudo +」を使用する必要があります。
sudo systemctl start .service上で述べたように、 `+ systemd `はサービス管理コマンドの ` *。service +`ファイルを探すことを知っているので、コマンドは次のように簡単に入力できます。
sudo systemctl start一般的な管理には上記の形式を使用できますが、わかりやすくするために、残りのコマンドに接尾辞「+ .service +」を使用して、操作対象を明示します。
現在実行中のサービスを停止するには、代わりに `+ stop +`コマンドを使用できます：
sudo systemctl stop .service再起動と再読み込み
実行中のサービスを再起動するには、 `+ restart +`コマンドを使用できます：
sudo systemctl restart .service問題のアプリケーションが（再起動せずに）設定ファイルをリロードできる場合、 `+ reload +`コマンドを発行してそのプロセスを開始できます：
sudo systemctl reload .serviceサービスに設定をリロードする機能があるかどうか不明な場合は、 `+ reload-or-restart +`コマンドを発行できます。 これにより、構成が利用可能な場合はその場で再ロードされます。 それ以外の場合は、サービスが再起動されるため、新しい構成が選択されます。
sudo systemctl reload-or-restart .serviceサービスの有効化と無効化
上記のコマンドは、現在のセッション中にコマンドを開始または停止するのに役立ちます。 `+ systemd `にブート時にサービスを自動的に開始するように指示するには、それらを有効にする必要があります。 +起動時にサービスを開始するには、 ` enable +`コマンドを使用します：
sudo systemctl enable .serviceこれにより、システムのサービスファイルのコピー（通常は+ / lib / systemd / system + または + / etc / systemd / system + ）からシンボリックリンクが作成され、 + systemd + がautostartを探すディスク上の場所に移動します。ファイル（通常は `+ / etc / systemd / system / .target.wants +。 このガイドの後半で、ターゲットについて説明します）。
サービスの自動開始を無効にするには、次のように入力します。
sudo systemctl disable .serviceこれにより、サービスを自動的に開始する必要があることを示すシンボリックリンクが削除されます。
サービスを有効にしても、現在のセッションでは開始されないことに注意してください。 サービスを開始して起動時に有効にしたい場合は、 `+ start `と ` enable +`コマンドの両方を発行する必要があります。
サービスの状態を確認する
システム上のサービスのステータスを確認するには、 `+ status of`コマンドを使用できます：
systemctl status .serviceこれにより、サービス状態、cgroup階層、および最初の数行のログが提供されます。
たとえば、Nginxサーバーのステータスを確認すると、次のような出力が表示される場合があります。
● 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 .serviceこれにより、現在のユニットの状態が返されます。通常は、「+ active 」または「 inactive 」です。 終了コードは、アクティブな場合は「0」になり、プログラムによる結果の解析がより簡単になります。 +ユニットが有効かどうかを確認するには、 ` is-enabled +`コマンドを使用できます：
systemctl is-enabled .serviceこれは、サービスが `+ enabled `または ` disabled +`であるかどうかを出力し、コマンドの質問に対する答えに応じて、終了コードを再び「0」または「1」に設定します。
3番目のチェックは、ユニットが故障状態にあるかどうかです。 これは、問題のユニットの起動に問題があったことを示しています。
systemctl is-failed .serviceこれは、正常に実行されている場合は「+ active 」を返し、エラーが発生した場合は「 failed 」を返します。 ユニットが意図的に停止された場合、「 unknown 」または「 inactive +」を返すことがあります。 「0」の終了ステータスは障害が発生したことを示し、「1」の終了ステータスは他のステータスを示します。
システム状態の概要
これまでのコマンドは、単一のサービスを管理するのに役立ちましたが、システムの現在の状態を調べるのにはあまり役立ちません。 この情報を提供する多くの `+ systemctl +`コマンドがあります。
現在のユニットのリスト
`+ systemd `が知っているすべてのアクティブユニットのリストを表示するには、 ` list-units +`コマンドを使用できます。
systemctl list-unitsこれにより、 `+ systemd +`が現在システム上でアクティブになっているすべてのユニットのリストが表示されます。 出力は次のようになります。
UNIT 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 *：これは、ユニットに関するより詳細な情報を示す低レベルの状態です。 これは多くの場合、ユニットのタイプ、状態、およびユニットが実行される実際の方法によって異なります。
-
説明：ユニットの内容/実行内容の短いテキストによる説明。
`+ list-units `コマンドはデフォルトでアクティブなユニットのみを表示するため、上記のエントリはすべてLOADカラムに「ロード済み」、ACTIVEカラムに「アクティブ」と表示されます。 この表示は、追加コマンドなしで呼び出された場合の実際の ` systemctl `のデフォルトの動作です。したがって、引数なしで ` systemctl +`を呼び出した場合も同じことがわかります。
systemctl追加のフラグを追加することで、さまざまな情報を出力するように+ systemctl に指示できます。 たとえば、現在アクティブであるかどうかに関係なく、 ` systemd `がロードした（またはロードしようとした）ユニットをすべて表示するには、次のように `-all +`フラグを使用できます。
systemctl list-units --allこれは、システムの現在の状態に関係なく、「+ systemd 」がロードした、またはロードしようとしたユニットを表示します。 一部のユニットは実行後に非アクティブになり、「 systemd +」がロードしようとしたユニットはディスク上で見つからなかった可能性があります。
他のフラグを使用して、これらの結果をフィルタリングできます。 たとえば、 `-state = +`フラグを使用して、表示したいLOAD、ACTIVE、またはSUB状態を示すことができます。 ` systemctl `が非アクティブなユニットを表示できるように、 `-all +`フラグを保持する必要があります。
systemctl list-units --all --state=inactive別の一般的なフィルターは、「-type = +」フィルターです。 興味のあるタイプのユニットのみを表示するように systemctl +に伝えることができます。 たとえば、アクティブなサービスユニットのみを表示するには、次を使用できます。
systemctl list-units --type=serviceすべてのユニットファイルのリスト
`+ list-units `コマンドは、 ` systemd `が解析してメモリにロードしようとしたユニットのみを表示します。 ` systemd `は必要だと思うユニットのみを読み込むため、これは必ずしもシステムで利用可能なすべてのユニットを含むとは限りません。 ` systemd `がロードを試みていないものを含め、 ` systemd `パス内の_every_利用可能なユニットファイルを表示するには、代わりに ` list-unit-files +`コマンドを使用できます。
systemctl list-unit-filesユニットは、 `+ systemd `が知っているリソースの表現です。 ` systemd +`は必ずしもこのビューのすべてのユニット定義を読み取ったわけではないため、ファイル自体に関する情報のみを表示します。 出力には、ユニットファイルと状態の2つの列があります。
UNIT 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
. . .通常、状態は「有効」、「無効」、「静的」、または「マスク」になります。 このコンテキストでは、静的とは、ユニットファイルにユニットを有効にするために使用される「インストール」セクションが含まれていないことを意味します。 そのため、これらのユニットは有効にできません。 通常、これは、ユニットが1回限りのアクションを実行するか、別のユニットの依存関係としてのみ使用され、単独で実行されるべきではないことを意味します。
「マスク」が意味することについては、すぐに取り上げます。
ユニット管理
これまで、サービスを操作し、 `+ systemd +`が知っているユニットとユニットファイルに関する情報を表示してきました。 ただし、いくつかの追加コマンドを使用して、ユニットに関するより具体的な情報を見つけることができます。
ユニットファイルの表示
`+ systemd `がシステムにロードしたユニットファイルを表示するには、 ` cat `コマンドを使用できます（これは ` systemd `バージョン209で追加されました）。 たとえば、 ` atd +`スケジューリングデーモンのユニットファイルを表示するには、次のように入力します。
systemctl cat atd.service[Unit]
Description=ATD daemon
[Service]
Type=forking
ExecStart=/usr/bin/atd
[Install]
WantedBy=multi-user.target出力は、現在実行中の「+ systemd +」プロセスに既知のユニットファイルです。 これは、ユニットファイルを最近変更した場合、またはユニットファイルフラグメントの特定のオプションをオーバーライドする場合に重要になることがあります（これについては後で説明します）。
依存関係の表示
ユニットの依存関係ツリーを表示するには、 `+ list-dependencies +`コマンドを使用できます：
systemctl list-dependencies sshd.serviceこれにより、問題のユニットを開始するために処理する必要がある依存関係をマッピングする階層が表示されます。 この文脈では、依存関係には、その上のユニットが必要とする、または必要とするユニットが含まれます。
sshd.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.serviceId=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 ConflictsConflicts=shutdown.targetユニットのマスキングとマスキング解除
サービス管理セクションでサービスを停止または無効にする方法を見ましたが、 `+ systemd `にはユニットを ` / dev / null `にリンクすることにより、自動または手動で_完全に起動不能としてマークする機能もあります。 これはユニットのマスキングと呼ばれ、 ` mask +`コマンドで可能です：
sudo systemctl mask nginx.serviceこれにより、Nginxサービスがマスクされている限り、自動または手動で開始されなくなります。
`+ list-unit-files +`をチェックすると、サービスがマスクされた状態でリストされていることがわかります。
systemctl list-unit-files. . .
kmod-static-nodes.service static
ldconfig.service static
mandb.service static
messagebus.service static
nginx.service
quotaon.service static
rc-local.service static
rdisc.service disabled
rescue.service static
. . .サービスを開始しようとすると、次のようなメッセージが表示されます。
sudo systemctl start nginx.serviceFailed to start nginx.service: Unit nginx.service is masked.ユニットのマスクを解除し、再び使用できるようにするには、単に `+ unmask +`コマンドを使用します：
sudo systemctl unmask nginx.serviceこれにより、ユニットが以前の状態に戻り、起動または有効化できるようになります。
ユニットファイルの編集
ユニットファイルの特定の形式はこのチュートリアルの範囲外ですが、 `+ systemctl `は、調整が必要な場合にユニットファイルを編集および変更するための組み込みメカニズムを提供します。 この機能は、 ` systemd +`バージョン218で追加されました。
デフォルトでは、 `+ edit +`コマンドは問題のユニットのユニットファイルスニペットを開きます：
sudo systemctl edit nginx.serviceこれは、ユニット定義にディレクティブをオーバーライドまたは追加するために使用できる空のファイルになります。 ディレクトリは、ユニットの名前に「+ .d 」が追加された「 / etc / systemd / system 」ディレクトリ内に作成されます。 たとえば、 ` 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 +」）で識別できます。 ターゲットはそれ自体あまり機能しませんが、代わりに他のユニットをグループ化するために使用されます。
これは、他の初期化システムがランレベルを使用するように、システムを特定の状態にするために使用できます。 特定の機能が利用可能な場合の参照として使用され、その状態を生成するために必要な個々のユニットの代わりに、目的の状態を指定できます。
たとえば、スワップの使用準備ができていることを示すために使用される「+ swap.target 」があります。 このプロセスの一部であるユニットは、設定で「 WantedBy = 」または「 RequiredBy = 」が「 swap.target 」であることを示すことで、このターゲットと同期できます。 スワップを使用可能にする必要があるユニットは、「 Wants = 」、「 Requires = 」、および「 After = +」の指定を使用してこの条件を指定し、関係の性質を示すことができます。
デフォルトターゲットの取得と設定
`+ systemd +`プロセスには、システムの起動時に使用するデフォルトのターゲットがあります。 その単一のターゲットからの依存関係のカスケードを満足させると、システムは望ましい状態になります。 システムのデフォルトターゲットを見つけるには、次のように入力します。
systemctl get-defaultmulti-user.target別のデフォルトターゲットを設定する場合は、 `+ set-default +`を使用できます。 たとえば、グラフィカルデスクトップがインストールされていて、システムをデフォルトで起動したい場合は、それに応じてデフォルトターゲットを変更できます。
sudo systemctl set-default graphical.target利用可能なターゲットのリスト
次のように入力すると、システムで使用可能なターゲットのリストを取得できます。
systemctl list-unit-files --type=targetランレベルとは異なり、複数のターゲットを一度にアクティブにできます。 アクティブなターゲットは、「+ systemd +」がターゲットに結び付けられたすべてのユニットを開始しようとし、それらを再び解体しようとしていないことを示します。 アクティブなターゲットをすべて表示するには、次を入力します。
systemctl list-units --type=targetターゲットの分離
ターゲットに関連付けられているすべてのユニットを開始し、依存関係ツリーの一部ではないすべてのユニットを停止することができます。 これを行うために必要なコマンドは、適切に「+ isolate +」と呼ばれます。 これは、他の初期化システムでランレベルを変更することに似ています。
たとえば、 `+ graphical.target `がアクティブなグラフィカル環境で操作している場合、 ` multi-user.target `を分離することにより、グラフィカルシステムをシャットダウンし、システムをマルチユーザーコマンドライン状態にすることができます。 。 ` graphical.target `は ` multi-user.target +`に依存していますが、その逆ではないため、すべてのグラフィックユニットが停止します。
この手順を実行する前に、重要なサービスを停止しないように、分離するターゲットの依存関係を確認することをお勧めします。
systemctl list-dependencies multi-user.target生き続けるユニットに満足したら、次のように入力してターゲットを分離できます。
sudo systemctl isolate multi-user.target重要なイベントにショートカットを使用する
電源オフや再起動などの重要なイベントに対して定義されたターゲットがあります。 ただし、 `+ systemctl +`には、機能を少し追加するショートカットもあります。
たとえば、システムをレスキュー（シングルユーザー）モードにするには、 `+ isolate rescue.target `の代わりに ` rescue +`コマンドを使用するだけです：
sudo systemctl rescueこれにより、ログインしているすべてのユーザーにイベントについて警告する追加機能が提供されます。
システムを停止するには、 `+ halt +`コマンドを使用できます：
sudo systemctl halt完全なシャットダウンを開始するには、 `+ poweroff +`コマンドを使用できます。
sudo systemctl poweroff再起動は `+ reboot +`コマンドで開始できます：
sudo systemctl rebootこれらのすべては、イベントが発生していることをユーザーに記録しますが、単にターゲットを実行したり、ターゲットを隔離したりすることはできません。 ほとんどのマシンは、これらの操作に対してより短く、より一般的なコマンドをリンクし、 `+ systemd +`で適切に動作することに注意してください。
たとえば、システムを再起動するには、通常次のように入力できます。
sudo reboot結論
ここまでで、 `+ systemd `インスタンスと対話して制御できる ` systemctl `コマンドの基本的な機能のいくつかに精通しているはずです。 ` systemctl +`ユーティリティは、サービスとシステムの状態管理のための対話のメインポイントになります。
「+ systemctl 」は主にコアの「 systemd 」プロセスで動作しますが、他のユーティリティによって制御される「 systemd 」エコシステムには他のコンポーネントがあります。 ログ管理やユーザーセッションなどの他の機能は、個別のデーモンと管理ユーティリティ（それぞれ「 journald + / + journalctl + および + logind + / + loginctl + `）によって処理されます。 これらの他のツールやデーモンに慣れるまで時間をかけると、管理が簡単になります。