19 systemd
デーモン #
systemd
は、システムを初期化します。このプロセスのIDは1です。systemd
はカーネルによって直接起動され、通常はプロセスを強制終了するシグナル9が使えないようにします。他のすべてのプログラムは、systemd
または子プロセスのいずれかによって直接起動されます。systemd
は、System V initデーモンの後継であり、(initスクリプトのサポートにより)System V initと完全に互換性があります。
systemd
の主な利点は、サービスの開始を並列化することによりブート時間を大幅に短縮できることです。さらに、systemd
は、サービスが必要なときだけ起動します。デーモンは、ブート時に無条件で起動されることはなく、最初に必要になったときに起動されます。systemd
は、カーネルコントロールグループ(cgroups)、スナップショットの作成、システム状態の復元もサポートしています。詳細については、https://www.freedesktop.org/wiki/Software/systemd/を参照してください。
systemd
Windows Subsystem for Linux (WSL)を使用すると、Microsoft WindowsオペレーティングシステムでLinuxアプリケーションおよびディストリビューションを実行できるようになります。WSLは、systemd
の代わりに、initプロセスを使用します。WSLで実行中のSLEDでsystemd
を有効にするには、プロセスを自動化するwsl_systemd
パターンをインストールします。
>
sudo
zypper in -t pattern wsl_systemd
または、/etc/wsl.conf
を編集して、次の行を手動で追加することもできます。
[boot] systemd=true
WSLでのsystemd
のサポートは部分的であり、systemd
ユニットファイルには、合理的なプロセス管理動作が必要であることに注意してください。
19.1 systemd
の概念 #
次のセクションでは、systemd
の背後にある概念について説明します。
systemd
は、System VおよびLSBのinitスクリプトと互換性のある、Linux向けのシステム/セッションマネージャです。systemd
の主な特徴は次のとおりです。
並列化機能
ソケットやD-Busアクティベーションによるサービスの起動
デーモンのオンデマンド起動
Linux cgroupsを使用したプロセスの追跡
システム状態のスナップショットの作成、およびその状態への復元
マウントポイントと自動マウントポイントの保持
精巧なトランザクションの依存関係に基づくサービス制御ロジックの実装
19.1.1 ユニットファイル #
ユニット設定ファイルには、サービス、ソケット、デバイス、マウントポイント、自動マウントポイント、スワップファイルやパーティション、起動ターゲット、監視対象のファイルシステムのパス、systemd
によって制御および監視されているタイマ、一時的なシステム状態のスナップショット、リソース管理スライス、または外部で作成されたプロセスグループに関する情報が含まれます。
「ユニットファイル」は、systemd
の次のファイルの総称です。
サービス. プロセスに関する情報(たとえば、実行中のデーモン)。サービスファイルは.serviceで終わります。
ターゲット. システム起動時のユニットのグループ化に、または同期ポイントとして使用されます。ターゲットファイルは.targetで終わります。
ソケット. ソケットに基づくアクティベーション(
inetd
など)でのIPC、ネットワークソケット、ファイルシステムFIFOに関する情報。ソケットファイルは.socketで終わります。パス. その他のユニットをトリガするために使用されます(たとえば、ファイル変更時のサービスの実行など)。パスファイルは.pathで終わります。
タイマ. タイマ制御された、タイマに基づくアクティベーションに関する情報。タイマファイルは.timerで終わります。
マウントポイント. 通常はfstabジェネレータによって自動生成されます。マウントポイントファイルは.mountで終わります。
自動マウントポイント. ファイルシステムの自動マウントポイントに関する情報。自動マウントポイントファイルは.automountで終わります。
スワップ. スワップデバイスに関する情報またはメモリページング用のファイル。スワップファイルは.swapで終わります。
デバイス. sysfs/udev(7)デバイスツリーに公開されているデバイスユニットに関する情報。デバイスファイルは.deviceで終わります。
スコープ/スライス. プロセスグループのリソースを階層管理する際の概念。スコープ/スライスファイルは.scope/.sliceで終わります。
systemd
ユニットファイルの詳細については、https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.htmlを参照してください。
19.2 基本的な使用方法 #
System V initシステムでは、initスクリプト、insserv
、telinit
などの複数のコマンドを使用してサービスを処理します。systemd
では、ほとんどのサービス関連のタスクを処理するコマンドが1つだけ(systemctl
)なので、サービスの管理が容易に行えます。git
やzypper
のように、「コマンドの後ろにサブコマンド」を指定して実行します。
systemctl GENERAL OPTIONS SUBCOMMAND SUBCOMMAND OPTIONS
完全なマニュアルについては、man 1 systemctl
を参照してください。
systemd
のコマンドは、出力先が端末である場合(パイプやファイルなどではない場合)、デフォルトではページャに長い出力が送信されます。ページングモードをオフにするには、--no-pager
オプションを使用してください。
systemd
では、bashによる補完もサポートしています。サブコマンドの最初の1文字を入力し、<Tab>を押すことで実行できます。この機能は、bash
シェルを利用している場合にのみ使用できるもので、bash-completion
パッケージをインストールしておく必要があります。
19.2.1 稼働中のシステムでのサービスの管理 #
サービスを管理するためのサブコマンドは、System V initでのサービス管理コマンドと同じ(start
、stop
など)です。サービス管理コマンドの基本構文は、以下のとおりです。
systemd
systemctl reload|restart|start|status|stop|... MY_SERVICE(S)
- System V init
rcMY_SERVICE(S) reload|restart|start|status|stop|...
systemd
では、複数のサービスを一括で管理できます。initスクリプトを次々と実行しなければならないSystem V initとは異なり、次のようにコマンドを実行します。
>
sudo
systemctl start MY_1ST_SERVICE MY_2ND_SERVICE
システムで利用できるすべてのサービスを一覧表示するには、次のように実行します。
>
sudo
systemctl list-unit-files --type=service
次の表に、systemd
とSystem V initの最も重要なサービス管理コマンドを示します。
タスク |
|
System V initコマンド |
---|---|---|
起動. |
start |
start |
停止. |
stop |
stop |
再起動. サービスを停止し、後で起動します。サービスがまだ起動していない場合は、そのサービスを起動します。 |
restart |
restart |
条件付きの再起動. サービスが現在実行中の場合、サービスを再起動します。実行されていないサービスについては、何も行いません。 |
try-restart |
try-restart |
再ロード.
サービスに対し、操作を中断せずに設定ファイルを再ロードするように指示します。Apacheに、変更後の |
reload |
reload |
再ロードまたは再起動. サービスが再ロードをサポートしていれば再ロードし、サポートしていなければ再起動します。サービスがまだ起動していない場合は、そのサービスを起動します。 |
reload-or-restart |
n/a |
条件付きの再ロードまたは再起動. サービスが再ロードをサポートしていれば再ロードし、サポートしていなければ再起動します(現在実行中の場合)。実行されていないサービスについては、何も行いません。 |
reload-or-try-restart |
n/a |
詳細なステータス情報の取得.
サービスのステータスについて、情報を表示します。 |
status |
status |
簡潔なステータス情報の取得. サービスがアクティブかどうかを示します。 |
is-active |
status |
19.2.2 サービスの恒久的な有効化/無効化 #
上述のサービス管理コマンドでは、現在のセッションに対するサービスを操作できます。systemd
では、サービスを恒久的に有効化/無効化して、必要に応じて自動的に起動したり、常に使用不可にすることもできます。この作業は、YaSTまたはコマンドラインを使用して実行できます。
19.2.2.1 コマンドラインからのサービスの有効化/無効化 #
次の表に、systemd
とSystem V initの有効化/無効化コマンドを示します。
コマンドラインからサービスを有効化した場合、そのサービスは自動的には起動されず、次回のシステム起動またはランレベル/ターゲット変更の際に起動されます。有効化した後で、即時にサービスを起動するには、systemctl start
MY_SERVICE
またはrc
MY_SERVICE start
のように、明示的にサービスを起動してください。
タスク |
|
System V initコマンド |
---|---|---|
有効化. |
|
|
無効化. |
|
|
確認. サービスが有効になっているかどうかを示します。 |
|
|
再有効化. サービスの再起動と同様に、このコマンドはいったんサービスを無効化した後に有効化します。サービスにデフォルト値を設定して再有効化する場合に利用します。 |
|
該当なし |
マスク. サービスを「無効化」しても、手動で起動できてしまいます。サービスを無効化するには、マスクを設定する必要があります。注意してご使用ください。 |
|
該当なし |
マスク解除. マスクを設定したサービスは、マスクを解除しないと使用できません。 |
|
該当なし |
19.3 システムの起動とターゲットの管理 #
システムを起動し、シャットダウンするプロセス全体は、systemd
によって管理されます。この点から見ると、カーネルは、他のプログラムからの要求に従って、他のすべてのプロセスを管理し、CPU時間とハードウェアアクセスを調整するバックグラウンドプロセスと考えることができます。
19.3.1 ターゲットとランレベルの比較 #
System V initでは、システムは「ランレベル」と呼ばれる状態でブートしていました。ランレベルはシステムの起動方法および稼働中のシステムで使用可能なサービスを定義します。ランレベルは番号付けされています。よく知られているランレベルは、0
(システムのシャットダウン)、3
(ネットワークを使用するマルチユーザシステム)、および5
(ネットワークとディスプレイマネージャを使用するマルチユーザシステム)です。
systemd
では、「ターゲットユニット」と呼ばれる仕組みを使用する新しい概念が導入されています。ただし、ランレベルの概念とも、完全な互換性を維持しています。ターゲットユニットには、番号ではなく名前が付けられており、特定の目的を果たします。たとえば、ターゲットlocal-fs.target
やswap.target
は、それぞれローカルファイルシステムのマウントと、スワップ領域のマウントを実行します。
ターゲットgraphical.target
は、ネットワーク機能とディスプレイマネージャ機能を使用するマルチユーザシステムで、ランレベル5に相当します。graphical.target
などの複合ターゲットは、他のターゲットのサブセットを組み合わせることで、「メタ」ターゲットとして機能します。systemd
では、既存のターゲットを組み合わせることで簡単にカスタムターゲットを作成できるため、非常に柔軟な運用が実現されます。
次のリストは、systemd
の最も重要なターゲットユニットを示しています。すべてを網羅したリストについては、man 7 systemd.special
を参照してください。
systemd
で選択できるターゲットユニット #default.target
デフォルトで起動されるターゲット。「実在する」ターゲットというよりは、別のターゲット(
graphic.target
など)に対するシンボリックリンクであるといえます。YaSTを介して恒久的に変更できます(19.4項 「YaSTを使用したサービスの管理」を参照)。セッション用に変更する場合は、ブートプロンプトで、カーネルパラメータsystemd.unit=MY_TARGET.target
を使用してください。emergency.target
コンソール上で最小限の緊急
root
シェルを起動します。ブートプロンプトでのみ、systemd.unit=emergency.target
と指定して使用します。graphical.target
ネットワークとマルチユーザをサポートし、ディスプレイマネージャを使用するシステムを起動します。
halt.target
システムをシャットダウンします。
mail-transfer-agent.target
メールの送受信に必要なすべてのサービスを起動します。
multi-user.target
ネットワークに対応したマルチユーザシステムを起動します。
reboot.target
システムを再起動します。
rescue.target
ネットワークに対応しないシングルユーザ
root
セッションを起動します。システム管理のための基本ツールが用意されています。rescue
ターゲットは、ログインの失敗やディスプレイドライバでの問題の解決など、複数のシステムの問題を解決するのに適しています。
System V initランレベルシステムとの互換性を維持するために、systemd
では、runlevelX.target
という名前の特別なターゲットが用意されています。それぞれXの部分がランレベルの番号に対応します。
現在のターゲットを検査するには、systemctl
get-default
コマンドを使用します。
systemd
のターゲットユニット #
System Vランレベル |
|
用途 |
---|---|---|
0 |
|
システムのシャットダウン |
1、S |
|
シングルユーザモード |
2 |
|
リモートネットワークなしのローカルマルチユーザ |
3 |
|
ネットワークを使用するフルマルチユーザ |
4 |
|
未使用/ユーザ定義 |
5 |
|
ネットワークとディスプレイマネージャを使用するフルマルチユーザ |
6 |
|
システムの再起動 |
systemd
は/etc/inittab
を無視する
System V initシステムのランレベルは、/etc/inittab
で設定されています。systemd
では、この設定が使用されることはありません。独自のブート可能なターゲットを作成する方法については、19.5.5項 「カスタムターゲットの作成」を参照してください。
19.3.1.1 ターゲット変更用のコマンド #
次のコマンドを使用して、ターゲットユニットを操作します。
タスク |
|
System V initコマンド |
---|---|---|
現在のターゲット/ランレベルの変更 |
|
|
デフォルトのターゲット/ランレベルへの変更 |
|
該当なし |
現在のターゲット/ランレベルの取得 |
|
あるいは、
|
デフォルトのランレベルの恒久的な変更 |
サービスマネージャを使用するか、次のコマンドを実行します。
|
サービスマネージャを使用するか、次の行を変更します。
での |
現在のブートプロセスに対するデフォルトランレベルの変更 |
ブートプロンプトで次のオプションを入力します。
|
ブートプロンプトで必要なランレベルの番号を入力します。 |
ターゲットやランレベルの依存関係の表示 |
「Requires」を指定すると、ハード依存関係(必ず解決する必要がある依存関係)が表示されます。「Wants」を指定すると、ソフト依存関係(可能であれば解決される依存関係)が表示されます。 |
該当なし |
19.3.2 システム起動のデバッグ #
systemd
には、システム起動プロセスを分析できる機能が用意されています。この機能により、全サービスのリストとそのステータスを(/var/log/
を解析することなく)確認することができます。systemd
では、起動手順を精査して、サービスの起動にかかっている時間を調べることもできます。
19.3.2.1 サービスの起動の確認 #
システムのブート後に起動された全サービスのリストを確認するには、systemctl
と入力します。次のように、すべてのアクティブなサービスが表示されます (一部省略しています)。特定のサービスの詳細情報が必要な場合は、systemctl status
MY_SERVICE
を使用してください。
#
systemctl
UNIT LOAD ACTIVE SUB JOB DESCRIPTION
[...]
iscsi.service loaded active exited Login and scanning of iSC+
kmod-static-nodes.service loaded active exited Create list of required s+
libvirtd.service loaded active running Virtualization daemon
nscd.service loaded active running Name Service Cache Daemon
chronyd.service loaded active running NTP Server Daemon
polkit.service loaded active running Authorization Manager
postfix.service loaded active running Postfix Mail Transport Ag+
rc-local.service loaded active exited /etc/init.d/boot.local Co+
rsyslog.service loaded active running System Logging Service
[...]
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
161 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
起動に失敗したサービスだけを表示する場合は、--failed
オプションを指定してください。
#
systemctl --failed
UNIT LOAD ACTIVE SUB JOB DESCRIPTION
apache2.service loaded failed failed apache
NetworkManager.service loaded failed failed Network Manager
plymouth-start.service loaded failed failed Show Plymouth Boot Screen
[...]
19.3.2.2 起動時間のデバッグ #
システムの起動時間をデバッグするために、systemd
では、systemd-analyze
コマンドが用意されています。このコマンドでは、全体の起動時間や起動時間順のサービス一覧を表示できるほか、他のサービスの起動時間と対比するために利用できる、SVG画像を生成することもできます。
- システムの起動時間の一覧表示
#
systemd-analyze Startup finished in 2666ms (kernel) + 21961ms (userspace) = 24628ms- サービスの起動時間の一覧表示
#
systemd-analyze blame 15.000s backup-rpmdb.service 14.879s mandb.service 7.646s backup-sysconfig.service 4.940s postfix.service 4.921s logrotate.service 4.640s libvirtd.service 4.519s display-manager.service 3.921s btrfsmaintenance-refresh.service 3.466s lvm2-monitor.service 2.774s plymouth-quit-wait.service 2.591s firewalld.service 2.137s initrd-switch-root.service 1.954s ModemManager.service 1.528s rsyslog.service 1.378s apparmor.service [...]- サービスの起動時間を表す画像
#
systemd-analyze plot > jupiter.example.com-startup.svg
19.3.2.3 起動プロセス全体の確認 #
上記のコマンドは、起動されるサービスとその起動時間を一覧にします。より詳細な概要については、ブートプロンプトで次のパラメータを指定して、完全な起動手順の詳細なログを作成するようにsystemd
に指示します。
systemd.log_level=debug systemd.log_target=kmsg
systemd
が、ログメッセージをカーネルのリングバッファに書き込むようになります。バッファを閲覧するには、dmesg
を使用してください。
>
dmesg -T | less
19.3.3 System Vとの互換性 #
systemd
はSystem Vと互換性があるため、引き続き既存のSystem V initスクリプトを使用できます。ただし、そのままではsystemd
でSystem V initスクリプトを使用できない既知の問題が少なくとも1つあります。initスクリプトでsu
またはsudo
を使用して別のユーザとしてサービスを起動すると、スクリプトエラーになり、「アクセス拒否」エラーが生成されます。
su
またはsudo
を使用してユーザを変更すると、PAMセッションが開始されます。このセッションは、initスクリプトが完了すると終了します。その結果、initスクリプトで起動されたサービスも終了します。このエラーを回避するには、次の手順に従います。
initスクリプトと同じ名前を持ち、ファイル名拡張子
.service
が付くサービスファイルラッパーを作成します。[Unit] Description=DESCRIPTION After=network.target [Service] User=USER Type=forking1 PIDFile=PATH TO PID FILE1 ExecStart=PATH TO INIT SCRIPT start ExecStop=PATH TO INIT SCRIPT stop ExecStopPost=/usr/bin/rm -f PATH TO PID FILE1 [Install] WantedBy=multi-user.target2
UPPERCASE LETTERSで記述されている値はすべて適切な値に置き換えてください。
systemctl start APPLICATION
コマンドで、デーモンを起動します。
19.4 YaSTを使用したサービスの管理 #
基本的なサービス管理は、YaSTサービスマネージャモジュールで行うこともできます。このモジュールは、サービスの起動、停止、有効化、および無効化をサポートしています。サービスのステータスを表示したり、デフォルトのターゲットを変更することもできます。
› › の順に選択して、YaSTモジュールを起動します。- の変更
システムのブート先になるターゲットを変更するには、
ドロップダウンボックスからターゲットを選択します。最もよく使用されているターゲットは、 (グラフィカルなログイン画面を起動する)と (コマンドラインモードでシステムを起動する)です。- サービスの起動または停止
テーブルからサービスを選択します。
列は、現在サービスが実行されているかどうかを示します( か、 かを示します)。ステータスを切り替えるには、 または を選択します。サービスを起動または停止すると、現在実行されているセッションのステータスが変更されます。再起動時にステータスを変更するには、サービスを有効化または無効化する必要があります。
- サービスの起動動作の定義
サービスは起動時に自動的に起動することも、手動で起動することもできます。テーブルからサービスを選択します。
列には、現在 で起動されているか、 に起動されているかが表示されます。ステータスを切り替えるには、 を選択します。現在のセッションのサービスステータスを変更するには、先に記載されているように、起動または停止する必要があります。
- ステータスメッセージの表示
サービスのステータスメッセージを表示するには、リストからサービスを選択し、
を選択します。出力は、コマンドsystemctl
-l
status MY_SERVICEで生成されたものと同じです。
19.5 カスタマイズsystemd
#
以下のセクションでは、systemd
ユニットファイルのカスタマイズ方法を説明しています。
19.5.1 ユニットファイルはどこに保存されていますか? #
SUSEによって提供されるsystemd
ユニットファイルは、/usr/lib/systemd/
に保存されています。カスタマイズされたユニットファイルとユニットファイルの「ドロップイン」は、/etc/systemd/
に保存されています。
systemd
をカスタマイズする場合は、/usr/lib/systemd/
ではなく、/etc/systemd/
ディレクトリを必ず使用してください。そうしないと、systemd
の次回の更新によって、変更内容が上書きされてしまいます。
19.5.2 ドロップインファイルによる上書き #
ドロップインファイル(または「ドロップイン」)は、ユニットファイルの特定の設定のみを上書きする部分的なユニットファイルです。ドロップインは、メイン設定ファイルより優先されます。コマンドsystemctl edit SERVICE
はデフォルトのテキストエディタを起動し、/etc/systemd/system/NAME.service.d/
に空のoverride.conf
ファイルを含むディレクトリを作成します。また、このコマンドは、実行中のsystemd
プロセスに変更について通知するようにします。
たとえば、システムがMariaDBを起動するまで待機する時間を変更するには、sudo systemctl edit mariadb.service
を実行し、開いたファイルを編集して、変更した行のみを含めます。
# Configures the time to wait for start-up/stop TimeoutSec=300
TimeoutSec
の値を調整して、変更を保存します。変更を有効にするには、sudo systemctl daemon-reload
を実行します。
詳細については、man 1 systemctl
コマンドで呼び出すことが可能なマニュアルページを参照してください。
systemctl edit --full
SERVICE
コマンドで--full
オプションを使用すると、元のユニットファイルのコピーが作成され、特定のオプションを変更できます。SUSEでユニットファイルが更新されると、その変更は、/etc/systemd/system/
ディレクトリのカスタマイズされたコピーによって上書きされるため、このようなカスタマイズはお勧めしません。さらに、SUSEがディストリビューションのドロップインに更新を提供する場合、--full
で作成されたユニットファイルのコピーが上書きされます。この混乱を回避し、常にカスタマイズを有効にするには、ドロップインを使用します。
19.5.3 ドロップインファイルを手動で作成する #
systemctl edit
コマンドを使用するのとは別に、優先度をより細かく制御できるように、ドロップインを手動で作成できます。このようなドロップインを使用すると、ファイル自体を編集したり、上書きしたりせずに、ユニットとデーモン両方の設定ファイルを拡張できます。次のディレクトリに保存されます。
/etc/systemd/*.conf.d/
、/etc/systemd/system/*.service.d/
システム管理者によって追加され、カスタマイズされたドロップイン。
/usr/lib/systemd/*.conf.d/
、/usr/lib/systemd/system/*.service.d/
アップストリーム設定を上書きするために、カスタマイズパッケージによってインストールされたドロップイン。たとえば、SUSEにはsystemd-default-settingsが付属しています。
ユニット検索パスのフルリストについては、man 5 systemd.unit
のマニュアルページを参照してください。
たとえば、systemd-journald
のデフォルト設定によって適用されるレート制限を無効にするには、次の手順に従います。
/etc/systemd/journald.conf.d
というディレクトリを作成します。>
sudo
mkdir /etc/systemd/journald.conf.d注記ディレクトリ名は、ドロップインファイルでパッチを適用するサービス名の後に付ける必要があります。
そのディレクトリに、上書きするオプションを指定して
/etc/systemd/journald.conf.d/60-rate-limit.conf
ファイルを作成します。次に例を示します。>
cat /etc/systemd/journald.conf.d/60-rate-limit.conf
# Disable rate limiting RateLimitIntervalSec=0変更を保存して、対応する
systemd
デーモンのサービスを再起動します。>
sudo
systemctl restart systemd-journald
ドロップインファイルとSUSEによって提供されるファイルとの間の名前の競合を回避するために、すべてのドロップインの前に2桁の数字とダッシュを付けることをお勧めします(たとえば、80-override.conf
)。
次の範囲が予約されています。
0-19
は、systemd
アップストリーム用に予約されています。20-29
は、SUSEによって提供されるsystemd
用に予約されています。30-39
は、systemd
以外のSUSEパッケージ用に予約されています。40-49
は、サードパーティのパッケージ用に予約されています。50
は、systemctl set-property
を使用して作成されたユニットドロップインファイル用に予約されています。
この範囲を超える2桁の数字を使用して、SUSEによって提供されるドロップインが独自のドロップインを上書きしないようにします。
systemctl cat $UNIT
を使用して、ユニット設定で考慮されるファイルを一覧表示し、確認することができます。
systemd
コンポーネントの設定は、ファイルシステムのさまざまな場所に分散している可能性があるため、全体的な概要を把握するのが難しい場合があります。systemd
コンポーネントの設定を調べるには、次のコマンドを使用します。
systemctl cat UNIT_PATTERN
は、1つ以上のsystemd
ユニットに関連する設定ファイルを出力します。次に例を示します。>
systemctl cat atd.servicesystemd-analyze cat-config DAEMON_NAME_OR_PATH
は、systemd
デーモンの設定ファイルとドロップインのコンテンツをコピーします。次に例を示します。>
systemd-analyze cat-config systemd/journald.conf
19.5.4 xinetd
サービスをsystemd
に変換する #
SUSE Linux Enterprise Desktop 15のリリース以降、xinetd
インフラストラクチャは削除されました。このセクションでは、既存のカスタムxinetd
サービスファイルを、systemd
ソケットに変換する方法の概要を説明します。
xinetd
サービスファイルごとに、少なくとも2つのsystemd
ユニットファイル(ソケットファイル(*.socket
)および関連するサービスファイル(*.service
))が必要です。ソケットファイルはどのソケットを作成するかをsystemd
に指示し、サービスファイルはどの実行可能ファイルを起動するかをsystemd
に指示します。
次のようなxinetd
サービスファイルの例を考えてみます。
#
cat /etc/xinetd.d/example
service example
{
socket_type = stream
protocol = tcp
port = 10085
wait = no
user = user
group = users
groups = yes
server = /usr/libexec/example/exampled
server_args = -auth=bsdtcp exampledump
disable = no
}
systemd
に変換するには、以下の2つの一致するファイルが必要です。
#
cat /usr/lib/systemd/system/example.socket
[Socket]
ListenStream=0.0.0.0:10085
Accept=false
[Install]
WantedBy=sockets.target
#
cat /usr/lib/systemd/system/example.service
[Unit]
Description=example
[Service]
ExecStart=/usr/libexec/example/exampled -auth=bsdtcp exampledump
User=user
Group=users
StandardInput=socket
systemd
「socket」と「service」ファイルオプションの完全なリストについては、systemd.socketおよびsystemd.serviceのマニュアルページ(man 5 systemd.socket
、man 5 systemd.service
)を参照してください。
19.5.5 カスタムターゲットの作成 #
System V init SUSEシステムでは、管理者が独自のランレベル設定を作成できるように、ランレベル4は使用されていません。systemd
では、任意の数のカスタムターゲットを作成できます。ターゲットの作成は、graphical.target
などの既存のターゲットを改変することから始めることをお勧めします。
設定ファイル
/usr/lib/systemd/system/graphical.target
を/etc/systemd/system/MY_TARGET.target
にコピーし、必要に応じて調整します。前のステップでコピーした設定ファイルは、すでにターゲットの必須な(「ハード」)依存関係を構築した状態になっています。希望する(「ソフト」)依存関係も構築するには、
/etc/systemd/system/MY_TARGET.target.wants
ディレクトリを作成します。希望するサービスごとに、
/usr/lib/systemd/system
から/etc/systemd/system/MY_TARGET.target.wants
へのシンボリックリンクを作成します。ターゲットの設定が完了したら、新しいターゲットを利用できるようにするために、
systemd
の設定を再ロードします。>
sudo
systemctl daemon-reload
19.6 高度な使用方法 #
次のセクションでは、システム管理者向けの高度なトピックについて説明します。さらに高度なsystemd
のドキュメントについては、Lennart Pöttering氏によるsystemd
の資料(https://0pointer.de/blog/projects/)を参照してください。
19.6.1 一時ディレクトリの消去 #
systemd
によって、定期的に一時ディレクトリを消去できます。前バージョンのシステムの設定は、自動的に移行されアクティブになります。一時ファイルを管理するtmpfiles.d
は、/etc/tmpfiles.d/*.conf
、/run/tmpfiles.d/*.conf
、および/usr/lib/tmpfiles.d/*.conf
ファイルからその設定を読み込みます。/etc/tmpfiles.d/*.conf
にある設定は、他の2つのディレクトリにある関連設定より優先します(/usr/lib/tmpfiles.d/*.conf
には、パッケージの設定ファイルが保存されています)。
設定のフォーマットは、パスごとに1行で、アクション、パス、およびオプションでモード、所有権、経過時間、引数のフィールドが含まれています(アクションによって変わります)。次の例は、X11ロックファイルのリンクを解除します。
Type Path Mode UID GID Age Argument r /tmp/.X[0-9]*-lock
tmpfile timerのステータスを取得するには、以下のようにします。
>
sudo
systemctl status systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.timer - Daily Cleanup of Temporary Directories Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.timer; static) Active: active (waiting) since Tue 2018-04-09 15:30:36 CEST; 1 weeks 6 days ago Docs: man:tmpfiles.d(5) man:systemd-tmpfiles(8) Apr 09 15:30:36 jupiter systemd[1]: Starting Daily Cleanup of Temporary Directories. Apr 09 15:30:36 jupiter systemd[1]: Started Daily Cleanup of Temporary Directories.
一時ファイルの処理について詳しくは、man 5
tmpfiles.d
を参照してください。
19.6.2 システムログ #
19.6.9項 「サービスのデバッグ」には、特定のサービスに対するログメッセージを閲覧する方法が説明されていますが、表示されるログメッセージは、サービスログからのものだけであるとは限りません。systemd
が記録したすべてのログメッセージ(「ジャーナル」と呼ばれる)にアクセスして問い合わせることもできます。最も古いログから始めて、すべてのログメッセージを表示するには、journalctl
コマンドを使用します。フィルタの適用や出力形式の変更については、man 1
journalctl
を参照してください。
19.6.3 スナップショット #
systemd
の現在の状態を名前付きのスナップショットに保存し、後でisolate
サブコマンドを使用してその状態に戻ることができます。定義した状態にいつでも戻ることができるため、サービスやカスタムターゲットをテストする際に便利です。スナップショットは現在のセッションでのみ使用可能で、システムを再起動すると自動的に削除されます。スナップショットの名前は、.snapshot
で終わる必要があります。
- スナップショットの作成
>
sudo
systemctl snapshot MY_SNAPSHOT.snapshot- スナップショットの削除
>
sudo
systemctl delete MY_SNAPSHOT.snapshot- スナップショットの表示
>
sudo
systemctl show MY_SNAPSHOT.snapshot- スナップショットの有効化
>
sudo
systemctl isolate MY_SNAPSHOT.snapshot
19.6.4 カーネルモジュールのロード #
systemd
により、/etc/modules-load.d
にある環境設定ファイルを使用してブート時に自動的にカーネルモジュールをロードできます。このファイルはMODULE.confという名前で、次のような内容です。
# load module MODULE at boot time MODULE
カーネルモジュールをロードするための設定ファイルがパッケージによってインストールされる場合、そのファイルは/usr/lib/modules-load.d
にインストールされます。同じ名前の環境設定ファイルが2つ存在する場合、/etc/modules-load.d
にあるファイルが優先されます。
詳細については、modules-load.d(5)
のマニュアルページを参照してください。
19.6.5 サービスのロード前にアクションを実行 #
System Vでは、サービスをロードする前に実行する必要のあるinitアクションは、/etc/init.d/before.local
に指定する必要がありました。この手順は、systemd
ではサポートされません。サービスの起動前にアクションを実行する必要がある場合、以下のようにしてください。
- カーネルモジュールのロード
ドロップインファイルを
/etc/modules-load.d
ディレクトリに作成します(構文は、man modules-load.d
を参照)。- ファイルまたはディレクトリの作成、ディレクトリの消去、所有権の変更
ドロップインファイルを
/etc/tmpfiles.d
に作成します(構文は、man tmpfiles.d
を参照)。- その他のタスク
システムサービスファイル(
/etc/systemd/system/before.service
など)を、次のテンプレートから作成します。[Unit] Before=NAME OF THE SERVICE YOU WANT THIS SERVICE TO BE STARTED BEFORE [Service] Type=oneshot RemainAfterExit=true ExecStart=YOUR_COMMAND # beware, executable is run directly, not through a shell, check the man pages # systemd.service and systemd.unit for full syntax [Install] # target in which to start the service WantedBy=multi-user.target #WantedBy=graphical.target
サービスファイルを作成したら、次のコマンドを実行する必要があります(
root
ユーザとして実行)。>
sudo
systemctl daemon-reload>
sudo
systemctl enable beforeサービスファイルを変更するたびに、以下を実行する必要があります。
>
sudo
systemctl daemon-reload
19.6.6 カーネルのコントロールグループ(cgroup) #
従来のSystem V initシステムでは、特定のプロセスを、その生成元のサービスと一致させることができないことがありました。Apacheなどの特定のサービスは、サードパーティのプロセス(CGIやJavaのプロセスなど)を多数生成し、サードパーティのプロセス自体もさらにプロセスを生成します。サービスに対する明確な割り当ては難しいことがあるだけでなく、場合によっては不可能であることもあります。特定の子プロセスを残して、サービスが正しく終了しないことも考えられます。
systemd
では、各プロセスを独自のcgroupに配置することでこの問題を解決しています。cgroupはプロセスをまとめるためのカーネルの機能で、すべての子プロセスを階層構造のグループとして管理します。systemd
では、各cgroupにそのサービスの名前が付けられています。非特権プロセスではcgroupから「離脱」できないため、サービスから生成したプロセスがどれなのかをサービス名によって判別できる効果的な仕組みです。
サービスに属するすべてのプロセスを表示するには、systemd-cgls
コマンドを使用します。次に例を示します。
#
systemd-cgls --no-pager
├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 20
├─user.slice
│ └─user-1000.slice
│ ├─session-102.scope
│ │ ├─12426 gdm-session-worker [pam/gdm-password]
│ │ ├─15831 gdm-session-worker [pam/gdm-password]
│ │ ├─15839 gdm-session-worker [pam/gdm-password]
│ │ ├─15858 /usr/lib/gnome-terminal-server
[...]
└─system.slice
├─systemd-hostnamed.service
│ └─17616 /usr/lib/systemd/systemd-hostnamed
├─cron.service
│ └─1689 /usr/sbin/cron -n
├─postfix.service
│ ├─ 1676 /usr/lib/postfix/master -w
│ ├─ 1679 qmgr -l -t fifo -u
│ └─15590 pickup -l -t fifo -u
├─sshd.service
│ └─1436 /usr/sbin/sshd -D
[...]
cgroupの詳細については、Chapter 10, Kernel control groupsを参照してください。
19.6.7 サービスの終了(シグナルの送信) #
19.6.6項 「カーネルのコントロールグループ(cgroup)」で説明したとおり、System V initのシステムでは、プロセスをその親サービスプロセスに割り当てることができないことがあります。そのため、サービスとその子プロセスを停止するのが難しくなります。終了されていない子プロセスは、ゾンビプロセスとして残ってしまいます。
各サービスをcgroupに範囲制約するという、systemd
の概念を採用することで、サービスのすべての子プロセスを判別し、それら各プロセスに対してシグナルを送信できます。サービスに対してシグナルを送信する場合は、systemctl kill
コマンドを使用します。使用可能なシグナルの一覧については、man 7 signals
を参照してください。
- サービスに対する
SIGTERM
の送信 SIGTERM
は、送信されるデフォルトのシグナルです。>
sudo
systemctl kill MY_SERVICE- サービスに対するSIGNALの送信
-s
オプションを使用することで、送信するシグナルを指定できます。>
sudo
systemctl kill -s SIGNAL MY_SERVICE- プロセスの選択
デフォルトでは、
kill
コマンドは、指定したcgroup内のall
(すべての)プロセスに対してシグナルを送信します。control
(制御)またはmain
(メイン)のプロセスに対してだけ送信することもできます。限定されたプロセスに対する送信は、SIGHUP
を送信して設定を再ロードさせるような場合に有効です。>
sudo
systemctl kill -s SIGHUP --kill-who=main MY_SERVICE
19.6.8 D-Busサービスに関する重要な注意事項 #
D-Busサービスは、systemd
クライアントと、pid 1として実行されるsystemdマネージャ間の通信用のメッセージバスです。dbus
はスタンドアロンのデーモンですが、初期化インフラストラクチャの不可欠な要素です。
動作中のシステムでdbus
を停止または再起動することは、PID 1の停止または再起動と同様の結果をもたらします。これにより、systemd
クライアント/サーバ通信が切断され、ほとんどのsystemd
機能が使用できなくなります。
したがって、dbus
の終了または再起動は推奨されず、サポートもされません。
dbus
またはdbus
に関連するパッケージを更新するには、再起動する必要があります。再起動が必要かどうか疑問に思う場合は、sudo zypper ps
-s
コマンドを実行します。dbus
が一覧表示されているサービスに表示される場合は、システムを再起動する必要があります。
自動更新が再起動が必要なパッケージをスキップするように設定されている場合でも、dbus
は更新されることに留意してください。
19.6.9 サービスのデバッグ #
デフォルトでは、systemd
は過剰に冗長な出力を行いません。サービスの起動が成功した場合は何も出力されず、失敗した場合は短いエラーメッセージが表示されます。ただし、systemctl
status
は、サービスの起動と動作をデバッグする手段を提供します。
systemd
は、独自のログ機構(「ジャーナル」)でシステムメッセージを記録します。これにより、サービスメッセージとステータスメッセージを両方とも表示できます。status
コマンドはtail
コマンドに似た動作をするほか、ログメッセージをさまざまな形式で表示することもできます。これにより、強力なデバッグツールとして利用できるようになっています。
- サービスの起動失敗の表示
サービスの起動に失敗した場合は、
systemctl status MY_SERVICE
を実行することで、詳細なエラーメッセージを表示することができます。#
systemctl start apache2 Job failed. See system journal and 'systemctl status' for details.#
systemctl status apache2 Loaded: loaded (/usr/lib/systemd/system/apache2.service; disabled) Active: failed (Result: exit-code) since Mon, 04 Apr 2018 16:52:26 +0200; 29s ago Process: 3088 ExecStart=/usr/sbin/start_apache2 -D SYSTEMD -k start (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/apache2.service Apr 04 16:52:26 g144 start_apache2[3088]: httpd2-prefork: Syntax error on line 205 of /etc/apache2/httpd.conf: Syntax error on li...alHost>- 直近N件のサービスメッセージの表示
status
サブコマンドは、デフォルトではサービスが出力した直近の10件のメッセージを表示します。表示するメッセージの件数を変更したい場合は、--lines=N
パラメータを使用して実行してください。>
sudo
systemctl status chronyd>
sudo
systemctl --lines=20 status chronyd- 追記モードによるサービスメッセージの表示
サービスメッセージを「リアルタイムに」を表示するには、
--follow
オプションを使用します。このオプションは、tail
-f
に似た動作をします。>
sudo
systemctl --follow status chronyd- メッセージの出力形式
--output=MODE
パラメータを指定すると、サービスメッセージの出力形式を変更できます。最も重要なモードには次のものがあります。short
デフォルトの形式。ログメッセージを、人間が読みやすいタイムスタンプと併記して表示します。
verbose
すべての項目を表示する完全な出力。
cat
タイムスタンプを併記しない、簡潔な出力。
19.7 systemd
タイマユニット #
cronと同様、systemd
タイマユニットは、Linuxでジョブをスケジュールするためのメカニズムを提供します。systemd
タイマユニットは、cronと同じ目的を果たしますが、いくつかの利点をがあります。
タイマユニットを使用してスケジュールされたジョブは、他の
systemd
サービスに依存する可能性があります。タイマユニットは通常の
systemd
サービスとして扱われるため、systemctl
で管理することができます。タイマにはリアルタイムと単調があります。
タイマユニットは
systemd
ジャーナルに記録されるため、監視とトラブルシューティングが容易になります。
systemd
タイマユニットは、.timer
ファイル名拡張子で識別されます。
19.7.1 systemd
タイマタイプ #
タイマユニットは、単調タイマとリアルタイムタイマを使用できます。
cronjobsと同様に、リアルタイムタイマはカレンダのイベントにトリガされます。リアルタイムタイマはオプション
OnCalendar
を使用して定義されます。単調タイマは特定の開始時点から指定の時間が経過するとトリガされます。後者はシステム起動イベントまたはまたはシステムユニットアクティベーションイベントのいずれかです。単調タイマを定義するオプションには、
OnBootSec
、OnUnitActiveSec
、OnTypeSec
などがあります。単調タイマは、永続的ではなく、再起動するたびにリセットされます。
19.7.2 systemd
タイマとサービスユニット #
すべてのタイマユニットには、それが制御する対応するsystemd
ユニットファイルが必要です。つまり、.timer
ファイルは、対応する.service
ファイルを有効にし、管理します。タイマとともに使用する場合、.service
ファイルには[Install]
セクションは必要ありません。サービスがタイマによって管理されるためです。
19.7.3 実例 #
systemd
タイマユニットの基本を理解するために、foo.sh
シェルスクリプトをトリガするタイマを設定します。
最初のステップは、シェルスクリプトを制御するsystemd
サービスユニットを作成することです。このファイルを作成するには、編集用に新しいテキストファイルを開いて、次のサービスユニット定義を追加します。
[Unit] Description="Foo shell script" [Service] ExecStart=/usr/local/bin/foo.sh
ファイルをfoo.service
という名前で/etc/systemd/system/
ディレクトリに保存します。
次に、編集用に新しいテキストファイルを開いて、次のタイマ定義を追加します。
[Unit] Description="Run foo shell script" [Timer] OnBootSec=5min OnUnitActiveSec=24h Unit=foo.service [Install] WantedBy=multi-user.target
上記の例の[Timer]
セクションは、トリガするサービス(foo.service
)とトリガするタイミングを指定します。この場合、オプションOnBootSec
はシステム起動の5分後にサービスをトリガする単調タイマを指定し、オプションOnUnitActiveSec
はサービスが有効になってから24時間後にサービスをトリガします(つまり、タイマは1日に1回サービスをトリガします)。最後に、オプションWantedBy
はシステムがマルチユーザターゲットに到達したときに、タイマが開始されるように指定します。
単調タイマの代わりに、オプションOnCalendar
を使用してリアルタイムタイマを指定できます。次のリアルタイムタイマ定義は週に1回、月曜日の12時に関連するサービスをトリガします。
[Timer] OnCalendar=weekly Persistent=true
オプションPersistent=true
は、タイマが最後の開始時刻を逃した場合(たとえば、システムの電源がオフになっているため)、タイマが有効化された直後にサービスがトリガされることを示します。
オプションOnCalendar
を使用して、次の形式で、サービスをトリガするための特定の日時を定義することもできます。DayOfWeek Year-Month-Day Hour:Minute:Second
。次の例は、毎日午前5時にサービスをトリガします。
OnCalendar=*-*-* 5:00:00
アスタリスクで任意の値を指定し、カンマで可能な値を列挙することができます。.. によって区切られた2つの値を使用して、連続した範囲を示します。次の例は毎月金曜日の午後6時にサービスをトリガします。
OnCalendar=Fri *-*-1..7 18:00:00
異なる時間にサービスをトリガするために、複数のOnCalendar
エントリを指定できます。
OnCalendar=Mon..Fri 10:00 OnCalendar=Sat,Sun 22:00
上記の例では、平日は午前10時、週末は午後10時にサービスがトリガされます。
タイマユニットファイルの編集が終了したら、foo.timer
という名前で/etc/systemd/system/
ディレクトリに保存します。作成したユニットファイルが正しいかどうかを確認するには、次のコマンドを実行します。
>
sudo
systemd-analyze verify /etc/systemd/system/foo.*
コマンドが出力を返さない場合、ファイルは検証に成功しています。
タイマを開始するには、コマンドsudo systemctl start
foo.timer
を使用します。起動時にタイマを有効にするには、コマンドsudo systemctl enable foo.timer
を使用します。
19.7.4 systemd
タイマの管理 #
タイマは通常のsystemd
ユニットとして扱われるため、systemctl
を使用して管理できます。たとえば、systemctl start
でタイマを起動し、systemctl enable
でタイマを有効にできます。また、コマンドsystemctl
list-timers
を使用して、すべてのアクティブタイマを一覧表示できます。非アクティブなタイマを含むすべてのタイマを一覧表示するには、コマンドsystemctl list-timers --all
を実行します。
19.8 詳細情報 #
systemd
の詳細については、次のオンラインリソースを参照してください。
- ホームページ
- 管理者向け
systemd
systemdの著者のうちの1人、Lennart Pöttering氏によるブログに、
systemd
に関する複数の投稿があります(本章記述時点では13個の投稿)。それらは、次のサイトに記載されています。https://0pointer.de/blog/projects/